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Executive  Summary 


Of  the  363  individuals  interviewed  for  Helix,  100%  agreed  that  experiences  were  the  most 
critical  Force  for  growing  systems  engineers.  Experiences,  combined  with  the  additional  Forces 
of  Mentoring  and  Education  &  Training,  make  up  the  career  paths  of  systems  engineers. 

From  2013  through  2017,  the  Helix  team  collected  and  analyzed  detailed  information  on  the 
careers  of  178  systems  engineers.  The  team  has  conducted  a  number  of  analyses  on  this  data, 
which  is  reported  here. 

In  particular,  this  Guidebook  provides  information  on: 

•  The  detailed  approaches  developed  to  analyze  and  assess  systems  engineering  career 
paths.  Instructions  for  individuals  or  organizations  to  assess  career  paths  can  be  found  in 
the  companion  Atlas  1.1  Implementation  Guide. 

•  Patterns  in  career  paths,  including  findings  in  terms  of  education,  experiences,  and 
organizations. 

•  Patterns  in  the  career  paths  of  chief  systems  engineers  (CSEs)  in  both  the  Helix  dataset 
and  the  International  Council  on  Systems  Engineering  (INCOSE)  Systems  Engineering 
Professional  (SEP)  certification  application  dataset. 

•  Frequently  asked  questions  about  career  paths,  which  synthetizes  statistical  findings 
reported  elsewhere  in  this  report.  This  section  interprets  preliminary  results  for  the 
benefit  of  systems  engineering  practitioners  as  well  as  for  systems  engineering  leaders. 

•  Insights  on  relating  career  paths  to  proficiency  and  project  performance.  This  section 
relates  career  paths  to  proficiency  in  systems  engineering.  It  also  describes  the 
relationship  between  proficiency  and  project  performance. 

This  Guidebook  is  intended  to  provide  individuals  and  organizations  with  critical  insights  on  the 
patterns  of  and  approaches  around  systems  engineers'  career  paths. 
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1.  Introduction 


The  Systems  Engineering  Research  Center  (SERC),  a  University  Affiliated  Research  Center 
(UARC),  set  up  by  the  U.S.  Department  of  Defense  (DoD),  responded  to  the  systems  engineering 
workforce  challenges  by  initiating  the  Helix  Project  to  investigate  the  "DNA"  of  systems 
engineers,  beginning  with  those  who  work  in  defense  and  then  more  broadly.  The  US  Deputy 
Assistant  Secretary  of  Defense  for  Systems  Engineering  (DASD(SE)),  the  International  Council  on 
Systems  Engineering  (INCOSE)  and  the  Systems  Engineering  Division  of  the  National  Defense 
Industrial  Association  (NDIA-SED)  jointly  sponsor  Helix.  To  ensure  Helix  delivers  the  greatest 
value  and  to  help  Helix  obtain  access  to  the  necessary  data.  Helix  formed  the  Helix  Advisory 
Panel  (HAP)  with  representatives  primarily  from  those  three  sponsor  organizations.  Helix  has 
held  four  annual  workshops  with  a  broad  set  of  representatives  from  across  government, 
academia,  and  industry.  Helix  is  a  multi-year  longitudinal  research  project,  which  has  gathered 
data  from  many  organizations  with  DoD  and  the  Defense  Industrial  Base  (DIB)  through  a 
combination  of  techniques,  including  interviews  with  hundreds  of  systems  engineers. 

Helix  project  started  in  2012  with  the  objective  to  explore  DoD  and  DIB  systems  engineering 
workforce.  Also,  it  aims  at  understanding  what  makes  systems  engineers  effective  and  why 
(Pyster  et  al.  2013a,  2013b,  2014,  2015  and  Hutchison  et  al.  2016  and  2018).  To  do  so.  Helix 
researchers  went  through  an  intensive  data  collection  that  involves  287  interviews  with 
systems  engineers,  peers  of  systems  engineers  and  their  leaders  and  managers.  Resulting  data 
consists  of  more  than  6000  interview  transcripts,  270  hours  of  audio,  resumes  and  curricula 
vitae.  Analysis  of  Helix  aggregated  data  seeks  to  identify  and  examine  common  experiences 
among  systems  engineers.  By  letting  patterns  emerge,  the  Helix  team  looks  to  characterize 
career  path  patterns  between  systems  engineers. 


1.1.  What  is  a  Career  Path? 

According  to  systems  engineers  in  the  Helix  sample,  the  key  forces  that  help  them  grow  and 
become  increasingly  effective  are  experiences,  mentoring,  and  education  and  training. 
Experiences  were  unanimously  reported  as  the  primary  force  that  enables  systems  engineers  to 
grow.  Most  often,  mentoring  was  listed  as  the  second-most  important  force.  Education  and 
training  were  consistently  described  as  important  for  growth,  but  less  critical  than  experiences 
and  mentoring.  This  aligns  with  Lombardo  and  Eichinger  (1996),  whose  research  on 
effectiveness  in  the  management  field  indicated  similar  results.  Though  using  slightly  different 
terminology,  Lombardo  and  Eichinger  stated  that  lessons  learned  by  successful  and  effective 
managers  are  roughly  70%  from  experiences,  20%  from  coworkers/mentors,  and  10%  from 
education  and  training.  (1996) 

Based  on  the  data  from  the  Helix  project,  the  way  that  these  forces  come  together  throughout 
an  individual's  career  makes  up  an  individual's  career  path. 

An  individual's  career  path  is  the  precise  combination  of  experiences,  mentoring,  and  education  & 
training  that  she  goes  through  during  her  career,  particularly  their  characteristics,  timing,  and 

order. 
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This  is  different  from  how  a  career  path  is  often  defined  in  the  human  resources  (HR) 
community,  which  tends  to  be  specific  to  individual  organizations.  For  example,  the  Society  for 
Human  Resource  Management  (SHRM)  defines  a  career  path  as,  "The  progression  of  jobs  in  an 
organization's  specific  occupational  fields  ranked  from  lowest  to  highest  in  the  hierarchal 
structure."  (SHRM  2015)  While  definitions  like  this  may  be  useful  for  classification  and 
management  of  positions,  they  are  focused  more  on  rigid  hierarchy,  provide  little  insight  into 
the  growth  and  development  of  individuals  throughout  their  careers,  and  may  provide  no 
insight  when  individuals  move  between  organizations. 

A  systems  engineer  will  develop  abilities  that  enable  her  to  take  on  greater  responsibility  as  she 
progresses  in  her  career,  but  often  will  move  between  professions  -  for  example,  moving  from 
electrical  engineering  to  systems  engineering  -  which  make  traditional  HR  definitions  of  career 
paths  obsolete.  Understanding  an  individual's  career  path  as  defined  by  Helix,  however,  can 
provide  critical  insights  into  her  capabilities.  Likewise,  understanding  how  systems  engineers 
build  capabilities  creates  the  opportunity  to  understand  patterns  in  career  paths  that  can  be 
used  to  guide  and  grow  systems  engineers  into  the  future. 

Among  the  forces,  experiences  and  education  were  the  first  chosen  for  more  intensive  analysis 
and  are  reflected  in  the  career  paths  reported  here.  In  understanding  the  forces,  the  distinction 
between  education  and  training  is  nuanced  -  both  involve  formal  instruction,  but  "education" 
refers  to  instruction  at  an  academic  institution  that  could  lead  to  an  academic  credential, 
typically  a  certificate  or  degree.  While  education  can  focus  on  a  specific  subject,  it  generally  is 
focused  on  a  broader  level  of  understanding.  "Training"  is  generally  focused  on  a  more  specific 
topic,  method,  or  approach  particular  to  the  individual's  employer.  The  types  of  training 
available  or  desired  are  strongly  dependent  on  organizational  context. 

Because  it  is  often  so  highly  tailored  to  an  organization,  few  patterns  in  "training"  have  been 
identified  across  organizations.  (Hutchison  et  al.  2016)  Likewise,  mentoring  is  a  force  for  growth 
that  has  a  place  at  any  point  in  a  systems  engineer's  career  and  the  type,  availability,  and 
success  of  mentoring  is  dependent  on  not  only  the  organization  but  also  the  individuals 
involved.  For  these  reasons,  pattern  analysis  currently  incorporates  only  data  based  on 
experiences  and  education. 


1.2.  Purpose  of  the  Guidebook 

The  Systems  Engineering  Career  Path  Guidebook  enables  systems  engineering  leaders  and 
practitioners  to  identify  patterns  and  common  practices  in  systems  engineers'  development 
and  can  be  used  by  systems  engineering  organizations  to  guide  the  development  of  their 
systems  engineers. 

The  systems  engineering  workforce  benefits  from  the  identification  of  career  path  patterns  as 
well  as  common  practices  by  recognizing  critical  competencies  or  proficiencies  in  systems 
engineering. 
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In  addition,  the  guidebook  provides  a  career  path  extraction  methodology  based  on  statistical 
and  text  mining  principles  to  be  used  by  systems  engineering  organizations,  systems 
engineering  leaders,  and  practitioners  when  needed  to  identify  overarching  career  patterns  in 
the  field  of  systems  engineering.  Specific  career  patterns  aim  at  facilitating  systems  engineering 
leaders  with  confidence  when  identifying  new  or  potential  systems  engineers  for  projects. 

Finally,  proficient  systems  engineers  improve  project  performance.  The  guidebook  aims  to 
enable  sponsors  to  identify  relationships  between  career  path  and  proficiency. 


1.3.  Anticipated  Users 

This  guidebook  is  intended  to  provide  guidance  to  advance  individuals'  systems  engineering 
capabilities  and  proficiencies.  It  is  intended  for  use  by  any  systems  engineer  and  any 
organization  which  has  identified  systems  engineering  as  a  critical  part  of  its  business  and 
wishes  to  grow  its  systems  engineering  workforce. 


1.4.  Layout  of  the  Guidebook 

The  guidebook  is  comprised  as  the  following: 

•  Section  2  -  Methodology,  describes  the  approach  developed  to  identify  systems 
engineering  career  paths. 

•  Section  3  -  Patterns  in  Career  Paths,  presents  findings  in  terms  of  education, 
experiences  and  organizations. 

•  Section  4  -  Answering  Frequently  Asked  Questions  about  Career  Paths,  synthetizes 
statistical  findings.  This  section  interprets  preliminary  results  for  the  benefit  of  systems 
engineering  practitioners  as  well  as  for  systems  engineering  leaders. 

•  Section  5  -  Bringing  Things  Full  Circle:  Relating  Career  Paths  to  Proficiency  and  Project 
Performance.  This  section  relates  career  paths  to  proficiency  in  systems  engineering.  It 
also  described  the  relationship  between  proficiency  and  project  performance. 

•  Section  6  -  Conclusions.  Provides  a  summary  of  findings,  and  recommendations. 


1.5.  Companion  Documents 

In  addition  to  this  Guidebook,  in  2018  the  Helix  team  delivered: 

•  Atlas  1.1:  The  Theory  of  Effective  Systems  Engineers  -  (SERC-2018-TR-101-A)  This  is  an 
incremental  evolution  of  Atlas  that  reflects  feedback  from  the  community,  additional 
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analysis,  and  maturation  of  the  team's  thinking  in  2017.  In  particular.  Atlas  includes 
minor  updates  on  the  values  systems  engineers  provide,  the  roles  systems  engineers 
play,  the  proficiency  model  for  systems  engineers,  and  the  personal  characteristics  of 
systems  engineers.  Henceforth,  this  will  be  referred  to  as  " Atlas  1.1". 

•  Atlas  1.1.  Implementation  Guide:  Moving  from  Theory  Into  Practice  -  (SERC-2018-TR- 
101-C)  Whenever  Atlas  is  presented,  there  are  many  questions  about  how  to  take  the 
theory  and  apply  it  in  practice.  The  Guide  provides  examples  from  organizations  that 
have  implemented  parts  of  Atlas,  and  guidance  created  by  the  Helix  team  based  on 
many  interactions  with  organizations  around  implementation  as  well  as  the  extensive 
Helix  dataset.  Henceforth,  this  will  be  referred  to  as  the  “Implementation  Guide". 

•  2017  Helix  Technical  Report  -  This  document  provides  an  overview  of  the  work 
completed  in  2017  along  with  the  team's  vision  and  planning  for  future  Helix  work.  It 
references,  rather  than  repeats,  the  findings  of  the  other  documents.  In  addition,  it 
captures  the  detailed  methodologies  utilized  on  the  Helix  project.  (SERC-2018-TR-101) 
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2.  Methodology 


The  research  methodology  adopted  for  Helix  research  may  be  considered  to  be  a  modified 
grounded  theory  based  approach,  employing  qualitative  and  quantitative  research  methods. 

From  2012-2014,  Helix  primarily  focused  on  data  collection  from  DoD  and  defense  industrial 
base  (DIB)  organizations  through  semi-structured  in-person  interviews  with  individuals  or  small 
groups,  continually  refining  the  interview  questions  and  process.  Follow-up  interviews  were 
conducted,  sometimes  by  telephone  with  most  of  the  participants.  In  2015,  the  Helix  team 
began  to  expand  the  dataset  to  organizations  outside  the  defense  sector  to  gather  additional 
patterns. 

The  Helix  project  adopted  a  grounded  theory  approach  because  it  did  not  presuppose  any 
specific  theory  or  propose  any  hypotheses  at  the  start  of  the  project.  Grounded  theory  was 
developed  in  the  social  sciences  as  a  method  for  developing  theory  that  is  grounded  in  data 
systematically  gathered  and  analyzed  (Goulding  2002).  Rather  than  beginning  with  a 
hypothesis,  the  first  step  is  data  collection.  This  approach  is  unusual  in  engineering  research, 
where  a  researcher  traditionally  begins  with  a  theoretical  framework  that  he  or  she  applies  to 
the  phenomenon  to  be  studied. 

In  the  Helix  project,  the  data  collected  from  the  many  semi-structured  interviews  were  marked 
up  with  codes  that  were  grouped  into  concepts  that  led  to  the  identification  of  constructs  and 
categories  that  formed  the  building  blocks  of  Atlas.  This  approach  minimized  any  bias  that 
might  be  introduced  by  the  researchers,  instead  allowing  the  large  data  set  collected  through 
the  Helix  project  to  drive  theory  development. 

Qualitative  research  aims  to  create  or  discover  what  things  are  made  of,  and  what  is  created  or 
discovered  are  called  constructs.  Qualitative  research  is  useful  for  obtaining  insight  into 
situations  and  problems  on  which  one  has  little  knowledge  a  priori.  This  method  is  commonly 
used  for  providing  in-depth  descriptions  of  procedures,  beliefs  and  knowledge,  including  the 
opinions  of  respondents  about  particular  issues;  detailed  data  is  gathered  through  open-ended 
questions. 

Data  collection  for  the  Helix  project  and  subsequent  analysis  of  the  data  was  primarily  done 
employing  qualitative  research  methods;  appropriate  software  tools  were  used  to  support 
coding  and  identification  of  constructs.  Quantitative  research  begins  once  initial  constructs  are 
in  hand.  It  attempts  to  gather  data  by  objective  methods  to  provide  information  about 
relations,  comparisons,  and  predictions.  In  the  context  of  the  Helix  project,  quantitative 
research  was  performed  once  initial  constructs  for  demographics  of  systems  engineers,  their 
organizations,  and  their  career  paths  were  established.  Data  was  collected  from  their  resumes 
as  well  as  through  pointed  questions  during  interviews. 
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2.1.  Career  Path  Methodology 


In  addition  to  the  analysis  of  interview  data,  the  Helix  team  developed  a  method  for  analyzing 
and  visualizing  career  paths  in  systems  engineering.  The  career  path  method  presented  here 
supplements  the  qualitative  data  analysis  described  earlier  with  more  quantitative  information 
about  an  individual's  career.  This  analysis  was  conducted  for  181  systems  engineers  from  a 
dozen  organizations.  The  initial  data  collection  for  career  analysis  was  conducted  by: 

•  Reviewing  the  resumes  submitted  by  each  individual,  including  chronology, 
organizations,  position  titles,  and  all  descriptive  text  provided  within  the  resumes, 

•  Reviewing  interview  transcripts  and  notes  to  add  detail  to  the  resume  data, 

•  Reviewing  the  preliminary  results  during  follow  up  interviews  to  clarify  analysis. 
Individuals  self-selected  whether  or  not  they  would  like  to  participate  in  follow-up 
interviews;  roughly  half  of  the  individuals  in  the  career  analysis  sample  have 
participated  in  follow-up  interviews,  and 

•  Comparing  the  career  paths  with  existing  Helix  research  on  the  proficiencies  of  systems 
engineers  and  how  career  path  elements  may  relate  to  these  proficiencies.  (Pyster  et  al. 
2014b,  Hutchison  2015,  Partacz  2017) 

By  using  this  approach,  the  Helix  team  developed  a  process  to  examine  experiences  and  a 
common  framework  to  capture,  analyze,  and  visualize  career  paths. 

This  guidebook  illustrates  the  extractions  of  career  path  based  on  systems  engineer's  education 
and  experience. 


2.1.1.  Characterizing  Systems  Engineer's  Education 

Education  plays  two  key  roles  in  the  development  of  systems  engineers.  First,  it  provides  the 
foundation  knowledge  to  support  engineering-related  work.  Typically,  this  takes  the  form  of 
undergraduate  education  in  an  engineering  discipline,  technical  field,  or  physical  science. 
Second,  graduate  level  education  is  an  avenue  to  develop  more  advanced  skills,  explore  more 
in-depth  knowledge,  and  help  systems  engineers  grow  as  they  move  through  their  careers. 

To  characterize  education  patterns,  the  following  academic  information  was  extracted  for  each 
systems  engineer  in  the  sample: 

•  Date.  The  date  of  the  completion  of  the  degree  program. 

•  Type  of  Degree.  This  is  the  level  of  education  an  individual  achieved.  The  categories 
used  were:  bachelor's,  master's,  and  doctor  of  philosophy  (PhD).  For  this  analysis,  only 
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education  that  resulted  in  a  degree  was  recorded.  Individuals  did  receive  graduate 
certificates  or  took  individual  courses,  but  there  was  not  enough  data  to  draw  any 
meaningful  conclusions.  Also,  if  a  degree  was  in  progress  but  not  completed,  it  was  not 
recorded. 

•  Field  of  Study.  The  primary  discipline  on  which  the  individual's  education  was  focused. 
These  were  initially  recorded  as  reported.  Over  time,  categories  of  related  fields  of 
study  were  created. 


2. 1.2. Characterizing  Systems  Engineer's  Experiences 

Experimental  literature  on  experiences  has  primarily  focused  on  two  metrics  for  experience: 
time  (e.g.  Ford  et  al.  1993;  Schmidt  et  al.  1986;  Firth  1979;  Davidz  2006)  and  the  frequency  of 
times  a  specific  task  or  activity  of  interest  was  performed.  Additional  literature  classifies  human 
subjects  based  on  their  experiences  -  which  is  subtly  different  than  classifying  the  experiences 
themselves  -  often  using  a  combination  of  time  and  the  frequency  of  tasks  performed.  This 
approach  may  also  include  considerations  for  specific  roles  played,  (Kor  2003,  Kirschenbaum 
1992).  Additional  literature  in  the  field  of  systems  engineering,  such  as  Sheard's  "Twelve 
Systems  Engineering  Roles"  (Sheard,  1996)  or  the  Graduate  Reference  Curriculum  for  Systems 
Engineering  (GRCSE)  (Pyster  et  al.  2012)  indicate,  though,  that  the  characterization  of 
experiences  is  critically  important  to  understanding  how  experiences  enable  growth. 

The  first  challenge  is  to  determine  a  common  "unit  of  measure"  for  experience.  Though  time  is 
common,  it  is  not  easily  used  in  the  data  available.  For  example,  if  someone  described  a 
position  they  held  over  a  five-year  period,  they  did  not  explain  the  portion  of  time  taken  up  by 
the  activities  they  performed  over  those  five  years.  In  addition,  several  individuals  submitted 
information  on  their  careers  that  included  detailed  descriptions,  but  did  not  include  markers  for 
chronological  time.  Because  of  these  data  limitations,  the  Helix  team  chose  to  use  a  position  as 
the  unit  of  measure  for  experience. 

Based  on  both  the  literature  and  the  Helix  data  itself,  each  position  has  several  characteristics: 

•  Relevance.  A  'relevant'  position  is  one  that  enables  a  systems  engineer  to  develop  the 
proficiencies  critical  to  systems  engineering. 

•  Position.  Every  systems  engineer  who  is  employed  at  an  organization  fills  a  position  that 
is  established  by  the  organization;  that  organization  also  defines  the  roles  and 
responsibilities  to  be  performed.  Helix  considers  position  as  a  'unit  of  measure'  for 
experience,  since  most  of  the  characteristics  of  experience  are  in  the  context  of  the 
position  that  is  held.  A  'systems  engineering'  position  is  one  where  the  individual's 
primary  focus  was  on  systems  engineering  activities. 


Report  No.  SERC-2018-TR-101-C 


8 


January  16,  2018 


•  Date.  A  position  typically  includes  a  starting  and  ending  year.  It  reflects  the  amount  of 
time  spent  in  a  position.  Within  the  data  described  in  Section  3,  "current"  positions  are 
evaluated  up  to  the  year  the  interview  was  conducted.  For  instance,  if  the  current 
position  started  in  2014  and  the  interview  was  conducted  in  2016,  the  participant  is 
considered  to  have  two  years  of  experience  at  the  current  position. 

•  Lifecycle  Stage.  Generic  systems  engineering  lifecycle  phases  considered  in  Atlas  are 
based  on  the  lifecycle  phases  in  the  Guide  to  the  Systems  Engineering  Body  of 
Knowledge  (SEBoK)  (BKCASE  Authors  2015).  Phases  include:  Concept  Definition,  System 
Definition,  System  Realization,  System  Deployment  and  Use,  Product  and  Service  Life 
Management,  and  Systems  Engineering  Management. 

•  Roles.  They  described  the  related  systems  engineering  activities  performed  at  the 
position  held.  Helix  team  identified  16  systems  engineering  roles  which  include:  Concept 
Creator,  Requirements  Owner,  System  Architect,  System  Integrator,  System  Analyst, 
Detailed  Designer,  V&V  Engineer,  Support  Engineer,  Systems  Engineering  Champion, 
Process  Engineer,  Customer  Interface,  Technical  Manager,  Information  Manager, 
Coordinator,  Instructor/Teacher. 

•  Number  of  Organizations.  The  number  of  different  organizations  that  an  individual  has 
worked  at,  not  counting  internal  movement  within  an  organization  across  departments 
or  divisions,  reflects  the  variety  of  types  of  experiences  that  one  may  possess.  The  three 
organizational  sectors  identified  are  government,  industry,  and  academia. 

•  Systems.  There  are  many  aspects  to  the  types  of  systems  on  which  a  systems  engineer 
could  work.  Working  across  these  different  categories  provides  valuable  experience  to 
an  individual  systems  engineer. 

o  Domain.  This  is  the  primary  area  of  application  for  the  systems  being  worked  on. 
However,  there  are  many  domain  categorizations;  some  domains  also  relate  to 
industry  sectors. 

o  Type.  Product  systems,  service  systems,  and  enterprise  systems  are  three  major 
types  of  systems,  depending  on  the  nature  and  composition  of  the  system  of 
interest.  System  of  systems  is  another  paradigm  in  systems  engineering,  and 
could  be  a  combination  of  one  or  more  types  of  systems. 

o  Level.  A  systems  engineer  could  work  on  various  levels  of  a  system: 
component/element,  subsystem,  system,  and  platform  or  system  of  systems. 

The  ways  in  which  positions  were  categorized  were  pulled  from  existing  literature  wherever 
possible.  For  example,  a  systems  engineer  working  in  the  commercial  sector  of  a  company  may 
define  lifecycle  in  different  terms  than  those  used  by  a  US  Department  of  Defense  systems 
engineer.  To  normalize  the  discussion,  the  definition  of  life  cycle  stages  from  the  Guide  to  the 
Systems  Engineering  Body  of  Knowledge  (SEBoK)  was  used;  the  interviewee's  own  words  and 
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phrasing  were  compared  with  the  descriptions  of  life  cycle  stages  in  the  SEBoK  and  categorized 
appropriately  (BKCASE  Editorial  Board,  2014).  Likewise,  the  roles  played  by  the  interviewees 
were  based  on  Sarah  Sheard's  "Twelve  Roles  of  Systems  Engineers"  (Sheard,  1996),  although 
roles  have  been  added  to  reflect  what  was  seen  in  the  data.  Where  existing  literature  was  not 
available,  categories  were  created  that  reflect  the  character  of  the  data. 

By  using  the  data  available  for  each  individual,  the  characteristics  of  each  position  and  the 
order  that  they  played  them  can  be  identified.  Then,  the  information  can  be  used  to  develop  a 
preliminary  understanding  of  how  career  paths  shape  proficiency. 


2. 1.3. Identifying  Key  Positions 

A  third  aspect  of  career  paths  are  the  key  milestones  for  a  systems  engineer's  career.  The  Helix 
team  focused  on  major  steps  or  changes  in  a  systems  engineer's  positions.  A  position  is 
equivalent  to  the  roles  and  responsibilities  associated  with  an  individual's  title.  Organizations 
will  define  what  roles  and  responsibilities  each  position  contains  and  position  descriptions  may 
not  translate  across  organizations.  The  key  positions  identified  for  systems  engineer  included: 

•  First  systems  engineering  position.  This  was  self-identified  by  participants  as  the  first 
position  in  which  systems  engineering  responsibilities  were  the  primary  focus  of  a 
position,  though  they  may  have  non-systems  engineering  responsibilities  as  well.  This 
was  often  difficult  to  identify,  because  participants  indicated  that  their  roles  often 
transitioned  gradually  and  it  was  hard  to  identify  when  they  officially  became  systems 
engineers,  especially  because  so  many  never  had  that  specific  title.  The  Helix  team 
recorded  this  information  in  whatever  way  it  was  provided  by  participants.  In  a  few 
organizations,  the  hierarchy  and  structure  for  becoming  a  systems  engineer  was  much 
more  well-defined,  and  for  individuals  in  those  organizations,  the  transition  to  systems 
engineer  was  more  easily  identified. 

•  Chief  systems  engineering  positions.  A  chief  systems  engineer  (CSE)  is  someone  who 
has  formal  responsibility  to  oversee  and  shepherd  the  technical  correctness  of  a  system, 
often  coordinating  with  many  other  systems  engineers  who  have  smaller  scopes  of 
responsibility.  These  milestones  are  any  positions  in  which  an  individual  acted  as  a  CSE, 
regardless  of  their  title  within  their  organization. 

•  Project  manager  positions.  A  project  manager  is  someone  who  has  formal  responsibility 
to  oversee  the  programmatic  aspects  of  a  system,  generally  focused  on  budget  and 
schedule.  Project  management  responsibilities  sometimes  overlap  with  SE 
responsibilities,  particularly  those  around  planning  and  management;  in  some  instances, 
a  CSE  may  also  function  as  a  PM. 

These  are  not  the  only  positions  that  could  be  identified  as  key.  For  example,  in  an  organization 
with  an  established  career  path  for  systems  engineers,  key  positions  for  that  organization 
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would  be  expected  to  be  highlighted.  This  could  include  positions  at  different  levels  of  seniority 
such  as  "systems  analyst"  or  "systems  architect". 


2.2.  Summary  Career  Path  Methodology 

Figure  1  illustrates  the  methodology  followed  by  the  Helix  team.  It  starts  by  collecting  data  in 
the  forms  of  resumes  or  curricula  vitae  and  oral  interviews,  in  some  instances  a  follow-up 
interview  was  required  to  either  to  clarify  or  collect  more  data.  The  available  data  is  then 
aggregated  and  classified  into  position,  education  and  key  position  attributes.  Analysis  on  the 
resulting  data  through  statistical  and  text  mining  principles  facilitate  the  identification  of 
patterns. 


i 


Figure  1.  Helix  methodology  for  career  path  analysis 

In  order  to  identify  and  characterize  systems  engineers,  the  Helix  team  created  a  classification 
mechanism  that  ranks  systems  engineers  according  to  their  seniority  level.  Systems  engineers 
are  then  classified  into  Junior,  Mid-Level  and  Senior  systems  engineers  according  to:  their 
exposure  to  leadership  positions,  experiences  at  different  system  levels  and  lifecycle  stages. 
Leadership  Positions  is  understood  as  the  number  of  formal  leadership  positions  recognized  by 
an  organization.  Complexity,  which  is  defined  as  the  level  of  impact  a  systems  engineer  has  on 
the  system  as  well  as  their  experience  at  the  system  level.  Lifecycle  Experience  is  described  as 
the  number  of  lifecycle  stages  in  which  a  participant  has  been  involved  to.  Lastly,  Roles  is 
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defined  as  the  total  number  of  positions  a  systems  engineer  has  performed.  Table  1  illustrates 
the  criteria  for  identifying  seniority  of  systems  engineers  in  the  Helix  dataset. 

Table  1.  Classification  rules  for  assessing  the  seniority  level  of  systems  engineers  in  the  Helix  dataset 


Criteria  for  Distinguishing  the  Seniority  of  Systems  Engineers 

Criteria 

Junior 

Mid-level 

Senior 

Leadership 

Primarily  works  as  an 
individual  contributor; 
has  had  zero  or  one 
formal  leadership 
positions,  which  can  be 
as  an  official  supervisor 
or  as  a  task  leader 

Has  had  at  least  two  formal 
leadership  positions  over 
teams  or  tasks  of  significant 
size  and  scope;  viewed  as  a 
leader  in  a  project, 
program,  or  business  unit  of 
the  larger  enterprise 

Three  or  more  formal 
leadership  positions  over 
teams  or  tasks  of 
significant  size  and  scope, 
including  second-level 
management  roles; 
viewed  as  a  leader  in  the 
enterprise 

Complexity 

Relevant  experiences 
on  a  simple  project, 
system,  or  task, 
working  primarily  at 
the  system 
components  level  or 
simple  activities  such 
as  managing  a 
requirements  database 

Relevant  experiences  on 
moderately  complex 
projects  or  systems, 
working  at  the  sub-system 
and  system  levels  or  on 
moderately  complex 
activities  such  as  managing 
the  development  and 
negotiation  of 
requirements  for  a 
moderately  complex  system 

Relevant  experiences  on 
complex  projects  or 
systems,  working  at  the 
system  and 
platforms/systems  of 
systems  levels  or  on  quite 
complex  activities  such  as 
managing  the 
development  and 
negotiation  of 
requirements  for  a 
complex  system  of 
systems 

Lifecycle 

Relevant  experiences  in 
at  least  two  phases  of 
the  systems  lifecycle 

Relevant  experiences  in  at 
least  three  phases  of  the 
systems  lifecycle 

Relevant  experiences  in  at 
least  four  phases  of  the 
systems  lifecycle 

Roles 

Worked  on  up  to  3 
different  roles 

Worked  on  4  to  6  different 

roles 

Worked  on  7  to  15 

different  roles 

Section  3  discusses  career  paths  in  systems  engineering  based  on  junior,  mid-level  and  senior 
systems  engineers. 
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2.3.  Assessing  your  Career  Path 


In  addition  to  reading  the  information  provided  here,  an  individual  may  choose  to  assess  his  or 
her  own  career  path.  The  specific  instructions  for  this  are  provided  in  the  Atlas  1.1 
Implementation  Guide,  and  mirror  the  methodology  described  above.  Helix  provides  two  tools 
for  this:  one  is  a  paper-based  career  path  template  (see  Appendix  C)  and  the  other  is  an  Excel- 
based  template  available  at  http://www.sercuarc.org/projects/helix.  It  is  worth  nothing  that  in 
addition  to  the  areas  for  which  there  were  clear  patterns,  which  are  reported  in  Section  3,  there 
are  other  areas  of  career  paths  that  individuals  or  organizations  may  wish  to  assess.  These 
include: 

•  Identifying  Key  Training.  For  some  individuals  in  the  Helix  dataset,  there  were  a  few  key 
training  opportunities  that  really  stood  out  as  helping  them  grow.  These  included 
trainings  such  as  week-long  leadership  retreats  or  two-week  rotations  into  other  parts 
of  the  organization.  The  idea  here  is  not  to  catalogue  every  training  course  you  have 
ever  taken,  but  to  highlight  training  that  has  been  particularly  impactful  and  put  it  on  a 
timeline  with  your  positions. 

•  Identifying  Key  Mentoring.  As  with  training,  mentoring  comes  in  many  different  forms. 
For  the  career  path,  it  is  useful  to  identify  areas  where  mentoring  was  particularly 
prevalent  and  can  be  tied  directly  to  growth.  Examples  in  the  Helix  dataset  included 
shadowing  where  a  senior  systems  engineer  sat  down  and  explained  all  of  the  ins  and 
outs  of  a  legacy  system  or  more  senior  systems  engineers  guiding  individuals  on  how  to 
deal  with  a  particular  customer  or  facet  of  systems  engineering. 

•  Creating  a  Career  Path  Timeline.  Visualizing  the  career  path  can  in  some  ways  be  just  as 
helpful  as  the  analysis  described  above.  It  is  the  opportunity  to  put  all  of  the  disparate 
pieces  of  your  career  path  together  and  look  at  them  more  holistically.  In  working  with 
individuals  to  create  their  self-assessments,  the  Helix  team  heard  things  like,  "Wow.  I 
thought  I  had  played  a  lot  of  different  systems  engineering  roles,  but  looks  at  this,  I 
need  to  diversify  more,"  or  "I  had  thought  I  had  spent  plenty  of  time  in  requirements, 
but  now  that  I  look  at  this,  it  has  only  been  a  small  part  of  my  career." 

This  is  not  to  say  that  there  is  a  "right"  or  "wrong"  career  path  -  but  this  holistic  view 
allows  you  to  identify  gaps  or  overlaps  in  a  clear  way.  It  also  provides  you  the 
opportunity  to  more  intentionally  plan  your  career  path  for  the  future.  For  example,  a 
gap  in  a  systems  engineering  role  may  encourage  you  to  focus  on  a  different  project  or 
type  of  work  than  you  otherwise  might.  And  it  should  be  noted  that  gaps  are  not  "bad"; 
most  career  paths  did  not  include  all  15  roles.  But  again,  it  allows  you  to  determine 
whether  this  is  acceptable  based  on  your  goals  or  whether  this  is  something  that  should 
be  addressed. 

Figure  2  provides  an  example  of  a  career  path  assessment  and  as  illustrated  in  the  figure, 
pairing  the  career  path  with  proficiency  assessments  can  provide  additional  insight. 
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Figure  2.  Example  career  path  of  a  chief  systems  engineer  from  the  Helix  sample. 


2.4.  The  Helix  Dataset  for  Career  Paths 

Helix  research  uses  a  bottom-up  approach,  based  on  the  data  being  analyzed.  Hence,  it  is 
essential  to  gather  data  that  is  sufficient  in  quantity  and  quality  to  enable  effective 
development  of  Atlas,  and  to  provide  reliable  insights  and  recommendations  that  can  be 
confidently  used  for  the  development  of  effective  systems  engineers. 


2.4.1.  Data  Sources 

The  primary  source  of  data  for  Helix  research  is  face-to-face  semi-structured  interviews  with 
participants  at  their  place  of  work.  Additional  information  about  the  participant  and  the 
organization  were  also  collected  as  available.  Another  data  source  that  Helix  gained  access  to 
was  the  application  data  for  the  INCOSE  Systems  Engineering  Professional  (SEP)  certification 
program. 
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Helix  Interview  Data 


From  June  2013,  when  Helix  conducted  its  first  site  visit  for  data  collection,  through  the  most 
recent  data  collection  in  November  2017,  a  total  of  363  participants  were  interviewed  from  23 
organizations.  Typically,  2  to  3  members  of  the  Helix  team  interviewed  anywhere  from  1  to  6 
participants  in  a  single  interview  session. 

Interview  participants,  if  willing,  also  provided  their  resumes  with  details  about  their 
educational  background,  work  experiences,  and  any  other  information  they  wished  to  provide. 

Follow-up  interviews  were  conducted  over  telephone  with  willing  participants,  to  explore  topics 
that  could  not  be  covered  in  the  initial  face-to-face  interviews  or  to  collect  additional 
information  based  on  their  resumes.  Follow-up  interviews  were  also  used  to  validate  results  of 
Helix  analysis. 

In  both  the  initial  interviews  as  well  as  follow-up  interviews,  transcripts  were  created  when 
audio  recording  was  permitted;  when  not  permitted,  summaries  were  prepared  from  notes 
taken  during  the  interviews.  These  transcripts  and  summaries  from  a  total  of  about  270  hours 
of  interviews  form  the  bulk  of  data  that  Helix  analyzed. 

The  data  that  was  analyzed  for  Atlas  1.1  and  presented  in  this  report  is  reflects  a  sub-set  of 
interviewees.  This  is  because  not  all  individuals  provided  enough  information  to  complete  a 
career  path  assessment.  Subsequent  reports  will  include  additional  analysis  performed  on  the 
Helix  interview  data. 


INCOSE  SEP  Application  Dataset 

INCOSE  provides  three  different  levels  of  SEP  certification:  Associate  (ASEP),  Certified  (CSEP), 
and  Expert  (ESEP).  Applicants  from  all  over  the  world  seeking  INCOSE  certification  apply  for  the 
appropriate  level  based  on  their  systems  engineering  experiences,  knowledge,  and 
accomplishment.  INCOSE  provided  to  Helix,  under  a  Non-Disclosure  Agreement,  over  3000 
application  forms  received  from  applicants  during  the  period  May  2004  to  May  2014.  Though 
the  application  data  was  available  in  electronic  form,  it  was  not  in  a  format  that  would  readily 
support  analysis.  Significant  time  and  effort  was  spent  in  extraction,  cleaning,  and  tabulating 
the  data  to  enable  further  analysis. 

Analysis  of  INCOSE  data  did  not  directly  contribute  to  the  building  of  Atlas,  but  provided  some 
validation  and  additional  insights  for  the  analysis  of  the  interview  data. 


2.4.2. Demographics  of  Helix  Dataset 

Understanding  the  sample  population  is  important,  since  the  interview  data  is  reflective  of  the 
population  from  which  it  has  been  collected,  and  in  turn,  that  data  is  the  basis  for  identifying 
career  paths.  Following  the  rubric  for  understanding  the  seniority  of  systems  engineers 
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presented  in  Table  1,  the  results  are  presented  in  Figure  3.  Senior  participants  cover  almost 
two-thirds  of  the  population  while  the  remaining  one-third  is  almost  split  almost  evenly 
between  junior  and  mid-Level  participants. 

Seniority  Level  Distribution 


Figure  3.  Distribution  of  seniority  levels  across  Helix  dataset 

Figure  4  illustrates  the  distribution  of  participants  based  on  the  "general  career  path 
classifications"  used  in  Partacz  (2017).  It  divides  the  sample  by  individuals  who  are  recognized  - 
and  recognize  themselves  as  systems  engineers  -  and  those  who  do  not.  A  third  category  "new 
engineer"  denotes  any  individual  with  less  than  nine  years  of  experience.  Note  that  this  is 
different  than  the  Helix  seniority  classifications,  which  do  not  depend  on  time. 

It  can  be  observed  that  more  than  two-thirds  of  Helix  participants  are  Experienced  Systems 
Engineers.  New  Engineers  are  slightly  behind  Experienced  Systems  Engineers  with  only  31%  of 
the  participants  being  allocated  to  New  Systems  Engineers.  On  the  other  hand,  an  almost  even 
distribution  occurred  among  Experienced  Systems  Engineers  who  have  never  been  officially 
titled  "systems  engineer"  and  those  who  have. 

General  Career  Path  Classification  Distribution 


Figure  4.  Distribution  of  career  path  classification  across  Helix  dataset 
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Figure  5  denotes  the  distribution  of  gender  across  the  Helix  dataset.  It  can  be  observed  that 
more  than  three-fourths  of  participants  are  male  systems  engineers.  In  each  organization,  the 
Helix  team  requested  additional  information  on  the  overarching  systems  engineering  workforce 
-  as  opposed  to  only  the  sampled  individuals.  Most  organizations  could  not  or  chose  not  to 
provide  this  information.  The  Helix  team  does  not  know  if  the  demographics  of  the  sample 
reflect  the  overarching  gender  demographics  of  the  populations  or  is  a  result  of  the  way  in 
which  organizations  selected  individuals  for  participation. 


2.4.1. Demographics  of  Career  Path  Dataset 

From  June  2013,  when  Helix  conducted  its  first  site  visit  for  data  collection,  through  the  most 
recent  data  collection  in  November  2017,  a  total  of  363  participants  were  interviewed  from  23 
organizations.  However,  the  analysis  conducted  here  is  based  on  complete  data  of  178 
participants  from  13  organizations.  Not  all  individuals  provided  enough  detail  for  the  team  to 
create  a  career  path.  The  most  successful  career  path  completion  included 

Participants  Gender  Distribution 

Female 


Figure  5.  Distribution  of  genders  across  Helix  dataset 


To  provide  a  more  detailed  context  about  Helix  findings,  it  is  helpful  to  understand  the 
domain  in  which  the  systems  engineers  interviewed  perform  their  activities.  As  it  can  be 
observed  in  Figure  6,  from  every  four  participants,  three  are  related  to  Defense 
organizations.  Multiple  Domains  domain  include  organizations  that  have  such  varied 
business  portfolios  that  no  single  one  could  be  selected. 
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Distribution  of  Individuals  by  Current  Domain 


Defense  Transportation  Multiple  Domains 


Domain 


Figure  6.  Individuals  by  current  domain 

Another  classification  of  the  type  of  participant  organizations  is  their  commercial  affiliation. 
Helix  classified  commercial  affiliation  into:  Government,  Industry  and  Federally  Funded 
Research  and  Development  Centers  (FFRDC).  As  it  can  be  observed  in  Figure  7,  more  than  half 
of  the  participants  belong  to  industry  organizations.  The  rest  of  the  dataset  is  distributed 
among  government  entities  and  FFRDC,  the  former  covering  10%,  while  direct  government 
organizations  cover  one-quarter  of  the  analyzed  dataset. 


Distribution  of  Individuals  by  Current  Organization  Type 
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Figure  7.  Individuals  by  current  organization  type 
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2.4.2. Demographics  of  INCOSE  SEP  Applicants 


From  the  pool  of  application  forms  received  by  the  Helix  team,  about  2500  unique  applicants 
were  identified  for  further  analysis.  The  filter  applied  was  whether  or  not  the  individual's 
information  was  complete  and  whether  they  had  received  certification.  The  rationale  was  that 
individuals  who  were  failed  to  complete  certification  process  may  have  done  so  based  on  their 
career  paths  not  meeting  the  INCOSE  requirements. 


Table  2.  Geographical  Distribution  of  INCOSE  SEP  Applicants 


Rank 

Country 

#  of  Applicants 

%  of  Total 

1. 

U.S. 

1847 

74% 

2. 

India 

179 

7% 

3. 

Germany 

151 

6% 

4. 

France 

101 

4% 

5. 

U.K. 

49 

2% 

6. 

Sweden 

41 

<2% 

7. 

Spain 

36 

1% 

Other 

100 

4% 

These  applicants  were  predominantly  from  the  U.S,  but  there  were  others  from  Asia  and 
Europe  as  well,  as  indicated  in  Table  2. 

The  INCOSE  SEP  application  data  did  not  include  gender.  It  did  include  date  of  birth,  from  which 
the  Helix  team  extrapolated  the  applicant  age  at  time  of  application,  which  is  reflected  in  Table 
3.  Not  that  the  average  age  was  consistent  year  by  year. 

Table  3.  Average  Age  of  INCOSE  SEP  Applicants  by  Certification  Type 


CERTIFICATION  TYPE 

AGE 

ASEP 

CSEP 

ESEP 

20-25 

15% 

1% 

0% 

25-30 

26% 

3% 

0% 

30-35 

21% 

16% 

0% 

35-40 

13% 

15% 

0% 

40-45 

15% 

15% 

1% 

45-50 

0% 

18% 

11% 

50-55 

4% 

16% 

33% 

55-60 

2% 

9% 

26% 

60-65 

4% 

5% 

17% 

65-75 

0% 

2% 

11% 

75-90 

0% 

0% 

1% 

Report  No.  SERC-2018-TR-101-C 


19 


January  16,  2018 


Information  from  all  the  2504  unique  applicants  was  used  for  analysis  of  education  background; 
a  subset  of  those  applicants  was  analyzed  for  experiences,  including  all  of  the  certified  ESEP 
applicants  and  a  selection  of  the  ASEP  and  CSEP  applicants.  The  reason  the  full  dataset  was  not 
used  for  experience  analysis  was  the  high  level  of  cleaning  required  to  create  consistency  in  the 
dataset. 
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3.  Patterns  In  Career  Paths 


Two  of  the  most  common  questions  the  Helix  team  receives  are,  "How  can  I  grow  as  a  systems 
engineer?"  and  "How  can  I  grow  the  systems  engineers  in  my  organization?"  The  first  way  the 
Helix  team  addresses  these  questions  is  by  examining  the  career  paths  of  systems  engineers  in 
the  dataset. 


3.1.  Education 

Education  patterns  are  related  to  the  background  knowledge  acquired  through  the  years  that 
facilitates  and  supports  the  execution  of  systems  engineering  activities.  The  Helix  team  started 
by  characterizing  all  the  completed  academic  degrees,  in  chronological  order.  Then,  the  team 
categorized  achieved  degree  into  bachelor's  and  master's  level.  Next,  degrees  were  clustered 
into  similar  fields.  For  instance,  "Computer  Engineering"  was  combined  with  "Computer 
Science"  this  facilitated  the  visualization  of  bachelor's  and  master's  degrees  earned. 

Figure  8  illustrates  the  differences  between  the  majors  at  the  graduate  and  undergraduate 
levels  in  the  sample.  Most  of  the  degrees  conferred  at  the  undergraduate  level  are  Science, 
Technology,  Engineering  and  Mathematics  (STEM)  related  degrees.  There  are  only  limited 
instances  where  the  area  of  expertise  is  liberal  arts,  or  other  non-technical  degrees.  On  the 
other  hand,  at  the  graduate  level.  Systems  Engineering,  Business  Administration  and  Electrical 
Engineering  cover  more  than  two-thirds  of  the  total  master's  degrees  conferred. 


Comparison  of  Degrees  Earned:  Bachelor's  vs  Master's 
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Figure  8.  Comparison  of  degrees  and  majors  achieved  in  Helix  dataset 
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To  provide  context.  Figure  9  provides  a  heat  map  of  the  Education  data  examined  by  the  Helix 
team  in  the  INCOSE  SEP  applicant  dataset.  In  the  figure  red  represents  the  lowest  incidence  of 
degrees  awarded  for  a  major,  while  great  represents  the  highest.  This  includes  all  applicants  for 
any  SEP  level,  so  would  cover  all  levels  of  seniority.  Of  note  is  that  electrical  engineering, 
mechanical  engineering,  and  computer  sciences  are  the  three  most  common  bachelor's  degree 
majors  -  in  that  order  -  among  the  SEP  applicants  as  well.  This  gives  the  Helix  team  confidence 
that  this  is  not  anomalous  to  the  Helix  dataset. 
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Figure  9.  Trends  in  bachelor's  degree  majors  among  INCOSE  SEP  applicants. 

Next,  to  identify  similarities  and  differences  among  systems  engineers,  it  is  necessary  to 
decompose  the  most  frequent  bachelor's  degrees  by  seniority  level.  Figure  10  shows  that  the 
electrical  engineering  major  is  the  most  popular  major  among  all  the  systems  engineers.  A  small 
difference  is  reflected  at  the  second  most  popular  major.  Junior  and  Senior  systems  engineers 
have  Mechanical  Engineering  as  a  preferred  undergraduate  major,  while  Mid-Level  systems 
engineers  typically  hold  computer-related  majors. 

Comparison  of  Bachelor's  Degree  Attained  by  Seniority  Level 
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Figure  10.  Comparison  of  bachelor's  degrees  attained  by  interviewed  systems  engineers 
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In  the  2000-2010  time  frame,  when  most  junior  systems  engineers  in  the  Helix  dataset  were 
attaining  their  education,  electrical,  mechanical,  and  civil  engineering  were  the  three  most 
common  majors  in  all  engineering  degrees  in  the  US,  although  their  ranking  changed  a  bit 
during  the  decade,  as  shown  in  Figure  11.  (NCES  2011)  The  percentages  for  junior  systems 
engineers  generally  align  with  the  overall  US  attainment  of  these  degrees  during  this  time 
period. 


Figure  11.  Comparison  of  most  popular  bachelor's  engineering  majors  in  the  US  from  2001-2010.  (NCES  2010) 

A  more  significant  variation  is  seen  at  the  master's  degree  level.  The  most  popular  major  for 
master's  degree  is  Systems  Engineering  for  Junior  and  Mid-level  engineers.  On  the  other  hand, 
data  reflects  that  Senior  systems  engineers  chose  Electrical  Engineering  and  Business 
Administration  as  preferred  graduate  level  majors.  Figure  12  shows  the  distribution  of  selected 
master's  degrees.  Junior  and  mid-level  engineers  adopted  Systems  Engineering  as  a  preferred 
major  while  Senior  engineers  chose  more  traditional  degrees.  Senior  systems  engineers  in  the 
dataset  explained  that  they  believed  they  had  sufficient  technical  skills,  but  wanted  to 
understand  the  business  case  for  their  engineering  work  and  were,  therefore  more  likely  to 
pursue  an  MBA.  Junior  systems  engineers,  on  the  other  hand,  were  more  likely  to  pursue  a 
degree  in  systems  engineering.  Again,  they  believed  their  general  engineering  skills  were 
sufficient,  but  that  they  needed  to  learn  more  about  systems  engineering  as  a  discipline. 
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Comparison  of  Master's  Degrees  Attained  by  Seniority  Level 
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Figure  12.  Comparison  of  master's  degrees  attained  by  interviewed  systems  engineers 

Again  it  is  useful  to  compare  the  Helix  interview  dataset  to  the  INCOSE  SEP  dataset.  The  trend 
in  increased  systems  engineering  master's  education  in  recent  years  certainly  matches  the  Helix 
patterns.  Interestingly,  MBAs  are  less  common  in  the  INCOSE  SEP  dataset,  though  this  data  also 
shows  a  growth  trend  over  time. 
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Figure  13.  Trends  in  master's  degree  majors  among  INCOSE  SEP  applicants 

There  is  a  steady  growth  trend  in  systems  engineering  graduate  education  in  the  US  (Lasfer  and 
Pyster  2013).  As  the  availability  of  systems  engineering  graduate  education  increases,  it  is 
reasonable  that  an  increased  number  of  junior  systems  engineers  would  seek  a  master's  in  the 
field.  This  cannot,  however,  account  for  the  fact  that  over  half  of  masters  degrees  awarded  to 
junior  systems  engineers  were  systems  engineering.  Junior  systems  engineers  explained  that 
they  sought  graduate  degrees  in  the  field  for  multiple  reasons: 
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•  To  learn  other  ways  of  doing  things.  Junior  systems  engineers  often  have  worked  in  only 
one  or  two  organizations.  Where  they  see  limitations  in  the  way  systems  engineering  is 
done  in  these  organizations,  they  often  feel  powerless  to  make  changes.  By  studying 
systems  engineering  academically,  however,  they  believe  they  can  better  understand 
alternatives  and  have  a  better  chance  of  making  an  impact  on  their  organization. 

•  Broadening  of  knowledge.  Junior  systems  engineers  almost  unanimously  expressed  a 
desire  to  see  different  parts  of  the  lifecycle,  experience  different  technologies, 
understand  new  techniques  in  the  field,  etc.  However,  these  experiences  are  not  always 
possible  in  their  current  organizations  or  may  not  be  available  as  soon  as  the  junior 
systems  engineers  desire.  By  obtaining  a  master's  degree  in  systems  engineering,  junior 
systems  engineers  can  at  least  gain  more  knowledge  on  the  aspects  of  systems 
engineering  they  have  not  yet  experienced,  understand  lifecycles  from  a  more  holistic 
perspective,  understand  multiple  processes,  and  gain  exposure  to  different  types  of 
tools.  While  all  of  the  junior  systems  engineers  who  have  graduate  degrees  in  systems 
engineering  indicated  that  they  learned  a  substantial  amount  in  their  programs  and  are 
happy  that  they  chose  to  pursue  a  master's  degree  in  the  field,  they  also  almost 
unanimously  expressed  concern  that  their  knowledge  and  skills  will  atrophy  if  they  are 
not  able  to  practice  them. 

•  General  career  growth.  Junior  systems  engineers  generally  expressed  a  desire  for 
growth  in  their  careers  and  believed  that  earning  a  master's  degree  in  the  discipline 
would  help  with  this  in  several  ways.  First,  simply  obtaining  graduate  level  education  in 
some  cases  made  them  eligible  for  promotions  or  other  incentives  that  they  otherwise 
would  not  have  had.  Second,  systems  engineers  are  often  in  the  position  of  having  to 
influence  engineering  decisions  without  having  authority  over  the  engineers  doing  the 
work  or  making  the  decisions.  Several  junior  systems  engineers  stated  that  having  a 
master's  degree  gave  them  at  least  some  level  of  "street  credit".  It  should  be  noted, 
however,  that  desire  for  growth  in  knowledge  and  skills  was  also  discussed  before 
career  growth  -  if  career  growth  was  discussed  at  all  -  and  always  to  a  greater  depth. 

In  terms  of  the  timing  of  graduate  education,  systems  engineers  on  average  pursue  a  graduate 
degree  in  less  than  eight  years  after  bachelor's  graduation.  As  it  can  be  seen  in  Figure  14,  more 
than  70%  of  junior  engineers  from  the  dataset  examined  received  a  graduate  degree  in  the 
following  3  to  5  years  after  obtaining  a  bachelor's  degree. 
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Number  of  Years  to  Receive  a  Masters  since  Bachelors  Graduation 
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Figure  14.  Comparison  of  number  of  years  to  receive  a  Master's  degree 

Also,  Figure  14  shows  a  more  spread  distribution  for  mid-level  and  senior  engineers.  Over  half 
of  mid-level  and  senior  systems  engineers  obtained  their  masters  degrees  between  3  and  8 
years  after  completing  their  graduate  degrees.  In  general,  junior  systems  engineers  in  the 
sample  reported  being  encouraged  to  pursue  a  master's  degree  soon  after  joining  their 
organizations.  Many  of  the  organizations  also  had  cohorts  of  systems  engineers  go  through 
master's  degree  programs,  which  again  explains  the  earlier  timing  of  graduate  education  and 
the  emphasis  on  systems  engineering  among  junior  systems  engineers. 

Another  aspect  the  Helix  team  considered  in  the  career  path  analysis  was  the  experiences  in 
systems  engineering.  Next  sections  discuss  systems  engineering  experiences  in  terms  of 
lifecycle,  roles,  system  type,  system  scope,  and  keyword  and  cluster  analysis. 

In  terms  of  doctoral  education,  8%  of  the  individuals  in  the  Helix  dataset  held  a  PhD.  The  areas 
of  study  for  these  degrees  is  shown  in  Figure  15. 

Table  4  Doctoral  areas  of  study  in  Helix  dataset 


Major 

Percentage 

Systems  Engineering 

31% 

Mechanical  Engineering 

19% 

Electrical  Engineering 

13% 

Technology  Management 

6% 

Atmospheric,  Oceanic,  and  Space  Sciences 

6% 

Geotechnical  Engineering 

6% 

Psychology 

13% 

Anthropology 

6% 
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In  the  INCOSE  SEP  dataset,  of  the  200  applicants  who  held  a  PhD  or  equivalent  degree  (Juris 
Doctor,  Doctor  of  Science,  etc.)  nearly  half  had  studied  either  electrical  or  systems  engineering, 
as  illustrated  in  Figure  15. 


Engineering  Major 
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Electrical  Engineering 
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Systems  Engineering 

23% 

Aeronautical  or  Astronautical  Engineering 

13% 

Mechanical  Engineering 

8% 
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General  Engineering 
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Other  Engineering 

19% 

Figure  15.  Doctoral  Areas  of  Study  in  INCOSE  SEP  Dataset 


The  comparison  of  the  doctoral  degrees  awarded  shows  that,  systems  engineering  is  the 
second  most  common  PhD  field  of  study  in  both  datasets. 


3.2.  Experiences 

Position  patterns  are  those  related  to  individuals  performing  systems  engineering  activities 
within  their  roles  and  responsibilities.  Position  is  considered  as  the  unit  of  measure  for 
experience  since  time  is  not  easily  identified  in  the  data  collected.  For  instance,  a  participant 
may  have  described  a  position  held  over  a  ten-year  period,  during  which  he  performed  multiple 
systems  engineering  activities  and  focused  on  different  system  levels,  but  did  not  necessarily 
described  the  time  spent  performing  the  different  activities.  Therefore,  due  to  those  limitations 
in  the  data  available,  position  was  considered  as  the  standard  unit  of  measure  for  experience. 

Experiences  in  systems  engineering  are  categorized  in  the  following:  lifecycle,  roles,  system 
type,  system  scope,  and  keyword  and  cluster  analysis. 


3.2.1.  Experiences  acros  the  Systems  Engineering  Lifecycle 

This  section  aims  to  depict  the  contrast  between  junior,  mid-Level,  and  senior  systems 
engineers  with  respect  to  their  experience  with  lifecycle  phases.  Table  5  describes  the  five 
lifecycle  phases  considered  based  on  the  Guide  to  the  Systems  Engineering  Body  of  Knowledge 
(SEBoK)  and  the  orthogonal  "Systems  Engineering  Management."  (BKCASE  Authors,  2015) 

Table  5.  Definition  on  lifecycle  phases  according  to  SEBoK  (BKCASE  Authors,  2015) 
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Lifecycle  Phase 


Definition 


Concept  Definition 

A  set  of  core  technical  activities  of  SE  in  which  the  problem  space  and  the 
needs  of  the  stakeholders  are  closely  examined.  This  consists  of  analysis  of  the 
problem  space,  business  or  mission  analysis,  and  the  definition  of  stakeholder 
needs  for  required  services  within  it. 

System  Definition 

A  set  of  core  technical  activities  of  SE,  including  the  activities  that  are 
completed  primarily  in  the  front-end  portion  of  the  system  design.  This 
consists  of  the  definition  of  system  requirements,  the  design  of  one  or  more 
logical  and  physical  architectures,  and  analysis  and  selection  between  possible 
solution  options. 

System  Realization 

The  activities  required  to  build  a  system,  integrate  disparate  system  elements, 
and  ensure  that  a  system  both  meets  the  needs  of  stakeholders  and  aligns 
with  the  requirements  identified  in  the  system  definition  stage.  This  includes 
integration,  verification,  and  validation  (IV&V) 

System  Deployment 
and  Use 

A  set  of  core  technical  activities  of  SE  to  ensure  that  the  developed  system  is 
operationally  acceptable  and  that  the  responsibility  for  the  effective,  efficient, 
and  safe  operations  of  the  system  is  transferred  to  the  owner.  Considerations 
for  deployment  and  use  must  be  included  throughout  the  system  life  cycle. 
Activities  within  this  stage  include  deployment,  operation,  maintenance,  and 
logistics 

Product  and  Service 
Life  Management 

Deals  with  the  overall  life  cycle  planning  and  support  of  a  system.  The  life  of  a 
product  or  service  spans  a  considerably  longer  period  of  time  than  the  time 
required  to  design  and  develop  the  system.  This  stage  includes  service  life 
extension,  updates,  upgrades,  and  modernization,  and  disposal  and 
retirement.  The  organizations  in  the  current  sample  are  primarily  concentrated 
on  new  development,  so  this  is  a  very  under-represented  aspect  of  the  life 
cycle. 

Systems  Engineering 
Management 

Managing  the  resources  and  assets  allocated  to  perform  SE  activities.  Activities 
include  planning,  assessment  and  control,  risk  management,  measurement, 
decision  management,  configuration  management,  information  management, 
and  quality  management.  These  activities  can  occur  at  any  point  in  the  systems 
engineering  lifecycle. 

To  map  the  systems  engineering  lifecycle  stages,  the  team  first  identified  every  single  relevant 
position  for  each  systems  engineer.  Then,  a  description  of  the  activities  performed  at  each 
position  supported  the  Helix  team  when  identifying  the  lifecycle  stages  the  engineer 
participated  in.  The  categorization  was  then  clustered  into  junior,  mid-level,  and  senior  systems 
engineer. 

Figure  16  denotes  the  distribution  of  lifecycle  stages  by  position  for  junior  systems  engineers. 
Note  that  not  all  junior  systems  engineers  have  had  five  positions  yet  in  their  careers;  the 
percentages  are  the  percent  of  junior  systems  engineers  who  reporting  having  that  position. 
Junior  systems  engineers  have  focused  primarily  on  System  Definition  over  their  careers. 
System  Realization  is  the  second  most  observed  stage  for  the  first  four  positions,  then  at 
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position  5,  junior  engineers  transition  to  Systems  Engineering  Management.  Note  that  not  all 
junior  systems  engineers  in  the  sample  have  five  positions. 


Junior  Systems  Engineers  -  Comparison  of  Lifecycle  Stages  by  Position 


■  Concept  Definition 

■  System  Realization 

Product  and  Service  Life  Management 


■  System  Definition 

■  System  Deploymentand  Use 

■  Systems  Engineering  Management 


Figure  16.  Comparison  of  lifecycle  stages  across  junior  systems  engineers 

Mid-Level  systems  engineers  experienced  more  variety  in  first  five  positions  compared  to  junior 
systems  engineers.  Figure  17  reflects  that  mid-Level  slightly  more  mid-level  systems  engineers 
in  the  sample  started  in  System  Realization,  often  performing  testing  or  other  V&V  related 
functions,  than  junior  systems  engineers.  In  positions  3-4,  System  Definition  is  the  most 
common  lifecycle  phase  experienced,  but  again  nearly  the  same  number  of  mid-level  systems 
engineers  experienced  System  Realization  in  these  positions.  In  position  5,  most  mid-level 
systems  engineers  reported  transitioning  to  leadership  or  management  roles.  As  it  can  be  seen, 
by  position  5  more  than  30%  of  mid-level  engineers  are  involved  in  the  Systems  Engineering 
and  Management  stage.  This  aligns  with  the  small  number  of  junior  systems  engineers  in  the 
sample  who  have  reached  position  5  and  also  have  become  more  engaged  with  Systems 
Engineering  Management. 
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Mid-Level  Systems  Engineers-  Comparison  of  Lifecycle  Stages  by  Position 
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Figure  17.  Comparison  of  lifecycle  stages  across  mid-level  systems  engineers 

This  pattern  -  of  significant  increases  in  Systems  Engineering  Management  -  repeats  for  senior 
systems  engineers,  as  shown  in  Figure  18.  In  a  similar  trend  with  respect  to  junior  and  mid-level 
systems  engineers,  senior  engineers  focus  on  the  first  four  positions  in  System  Definition  and 
System  Realization  stages.  Also,  position  1  for  senior  and  mid-level  engineers  reflects  that  both 
seniority  levels  were  slightly  more  likely  to  start  their  career  at  System  Realization,  in  contrast 
to  junior  engineers  who  were  more  likely  to  begin  at  System  Definition.  Lastly,  Systems 
Engineering  and  Management  is  the  most  frequent  stage  starting  at  position  5  and  position  6. 
This  is  due  to  the  fact  that  senior  engineers  take  over  leadership  or  management  roles. 
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Senior  Systems  Engineers  -  Comparison  of  Lifecycle  Stages  by  Position 
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Figure  18.  Comparison  of  lifecycle  stages  across  senior  systems  engineers 


Interpreting  the  Results 

What  does  this  view  of  lifecycle  stages  mean?  The  first  is  that  there  is  no  one  single  way  to 
move  through  the  systems  engineering  lifecycle.  There  are  a  clear  patterns  -  overall  System 
Definition  and  System  Realization  are  common  lifecycle  phases  across  all  positions  and  around 
position  5,  a  systems  engineer  would  be  expected  to  start  engaging  in  systems  engineering 
management.  However,  when  the  Helix  team  tried  to  map  all  of  the  different  paths  through  the 
phases  of  the  lifecycle,  they  discovered  78  distinct  paths!  In  fact,  no  single  path  was  followed  by 
more  than  6%  of  the  sample  and  this  6%  were  junior  systems  engineers  with  only  two  lifecycle 
stages  in  their  career  paths  -  meaning  they  could  still  diverge.  Therefore,  the  patterns 
highlighted  above  actually  provide  more  insight  than  a  single,  particular  career  path.  Some  key 
items  to  note: 

•  None  of  the  systems  engineers  in  the  sample  have  experience  in  only  one  aspect  of  the 
life  cycle.  It  was  stated  repeatedly  in  both  initial  and  follow  up  interviews  that  it  is 
critical  that  systems  engineers  understand  multiple  stages  of  the  life  cycle.  This  data 
seems  to  confirm  the  general  belief  that  an  individual  who  has  experienced  only  one 
stage  of  the  life  cycle  is  likely  not  ready  to  be  a  systems  engineer.  It  also  aligns  with  the 
Helix  seniority  framework,  which  identifies  an  individual  as  a  junior  systems  engineer 
only  if  they  have  experience  in  at  least  two  lifecycle  stages. 

•  Around  9%  of  the  individuals  in  the  current  sample  have  experience  in  all  lifecycle  stages 
plus  systems  engineering  management.  In  the  current  organizational  sample,  most 
organizations  were  not  heavily  involved  in  modernization  or  disposal  efforts,  limiting  the 
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number  of  individuals  who  have  the  possibility  of  experiencing  "Produce  and  Service  Life 
Management."  About  17%  have  experiences  in  5  stages. 

•  The  majority  (about  77%)  of  the  senior  systems  engineers  in  the  current  analysis  have 
experience  in  four  or  more  stages  of  the  life  cycle.  This  aligns  with  the  assumption  that 
senior  systems  engineers  develop  in  part  by  exposure  across  the  life  cycle.  Again,  this  is 
primarily  from  industry  as  most  government  resumes  did  not  include  this  level  of  detail. 
This  is  one  of  the  criteria  for  a  senior  systems  engineer.  The  other  senior  systems 
engineers  tended  to  be  younger,  so  had  seen  fewer  lifecycles  but  help  many  leadership 
positions,  worked  at  the  system  levels,  and  played  many  roles  (fulfilling  all  but  the 
lifecycle  guidance  to  be  classified  as  "senior"). 

There  are  plenty  of  opinions  on  "the  right"  way  through  the  lifecycle  -  in  fact,  in  the  Helix 
dataset,  there  were  two  very  strong  recommendations  for  senior  systems  engineers:  start  at 
the  beginning  of  the  lifecycle  and  work  through  the  entire  cycle  until  the  end  or  start  at  the  end 
and  work  through  the  entire  cycle  through  to  the  beginning.  In  fact,  only  one  individual  went 
through  the  lifecycle  from  Concept  Definition  through  to  Product  and  Service  Life  Management 
in  order  (and  even  that  individual  focused  on  Systems  Engineering  Management  before  getting 
to  Product  and  Service  Life  Management).  There  was  no  one  in  the  sample  that  had  been 
through  the  entire  lifecycle  backwards  and  very  few  started  with  "Product  and  Service  Life 
Management". 

There  are  some  challenges  to  both  of  these  approaches  -  namely  that,  particularly  in  traditional 
defense  programs,  lifecycles  tend  to  be  long  and  the  amount  of  time  it  would  take  to  see  a 
lifecycle  through  to  completion  on  a  program  can  be  several  years.  Many  senior  systems 
engineers  recommended  going  through  the  lifecycle  on  a  single  program  -  but  again,  with  some 
programs  lasting  20  years  or  longer,  this  is  a  difficult  development  path.  Working  backwards 
through  the  lifecycle  has  the  same  problems  -  and  the  added  difficulty  of  having  to  learn  a  new 
program  with  each  move.  Even  outside  of  defense,  this  can  be  difficult.  For  example,  the 
average  time  from  concept  generation  to  fielding  a  system  in  the  FAA  is  seven  years.  In  some 
commercial  sectors,  program  times  may  be  shorter,  making  this  sort  of  holistic  approach  more 
feasible. 

However,  as  discussed  above  there  are  many  successful  systems  engineers  who  did  not  take 
either  of  these  paths  through  the  lifecycle.  When  the  Helix  team  asked  individuals  to  describe 
the  rationale  behind  their  recommendations  in  interviews,  and  interestingly  -  and  perhaps  not 
surprisingly  -  most  recommended  a  path  similar  to  the  one  they  had  taken.  Several  went  on  to 
explain,  however,  that  it  was  less  the  order  in  which  the  individuals  experienced  the  lifecycle 
and  more  the  ability  to  take  learning  from  one  area  and  apply  it  to  another.  There  were  many 
examples  of  this,  but  a  few  are  included  here:  discovering  design  problems  rooted  in  allocation 
of  requirements  in  testing  and  taking  that  knowledge  into  their  eventual  design  work  to  avoid 
those  same  problems;  identifying  gaps  in  the  understanding  of  an  engineering  team  and  the 
end  user  as  operators  or  maintainers  and  bringing  that  perspective  into  design  or  testing  to 
ensure  better  alignment;  failing  a  validation  test  and  realizing  that  lack  of  understanding  of  the 
customer  needs  was  the  primary  problem;  having  to  test  one's  own  designs  and  realizing  the 
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flaws  in  them.  All  of  these  anecdotes  illustrated  a  pattern  that  highlighted  one  of  the  Atlas 
proficiencies:  abstraction,  the  ability  to  filter  out  and  understand  the  critical  bits  of  information 
at  the  right  level  and  to  make  relevant  inferences.  It  also  helps  them  to  be  able  to  identify 
patterns  and  apply  them  in  different  contexts. 


3.2.2.Roles 

A  position  held  by  an  individual  is  equivalent  to  a  'title',  where  the  organization  defines  what 
roles  and  responsibilities  it  entails.  Each  position  has  a  variety  of  characteristics,  which  align 
with  the  characteristics  of  experiences  including  the  length  of  the  position,  the  types  of  systems 
worked  on  in  that  position,  the  roles  played,  and  the  aspects  of  the  lifecycle  seen. 

An  individual  systems  engineer  fills  a  position  (or  holds  a  title)  in  an  organization,  and  there  are 
many  roles  that  the  systems  engineer  is  expected  to  perform  in  that  position.  Atlas  identifies  15 
systems  engineering  roles;  typically,  a  systems  engineer  performs  a  combination  of  these  roles 
while  holding  a  single  position.  Starting  with  the  'twelve  systems  engineering  roles'  identified 
by  Sheard  (1996).  The  Helix  team  recombined,  renamed,  removed,  and  added  roles  to  reflect 
the  Helix  data  collected  during  interviews  about  the  activities  systems  engineers  perform  in 
organizations  today.  This  was  socialized  with  the  community  through  conference  papers  and 
presentations,  the  Helix  workshops,  and  through  early  adopter  activities  with  several 
organizations. 

Table  6  highlights  the  clustering  of  roles  suggested  by  the  Helix  team  in  three  categories: 

•  Roles  Focused  on  the  System  Being  Developed.  These  roles  are  what  may  most  quickly 
come  to  mind  when  describing  a  systems  engineer.  They  are  roles  that  align  closely  with 
the  systems  engineering  lifecycle  and  the  critical  activities  systems  engineers  must 
enable  throughout  the  lifecycle. 

•  Roles  Focused  on  SE  Process  and  Organization.  These  roles  focus  on  the  organizational 
context  in  which  systems  engineering  occurs  and  the  critical  role  of  systems  engineers  in 
providing  guidance  on  how  systems  engineering  should  be  utilized. 

•  Roles  Focused  on  Teams  That  Build  Systems.  Systems  engineering  does  not  occur  in  a 
vacuum;  it  is,  instead,  an  intensely  social  discipline.  The  roles  in  this  category  are  those 
that  focus  on  enabling  diverse,  multi-disciplinary  teams  to  be  successful. 
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Table  6.  Description  of  systems  engineering  roles  identified  by  Helix 


Role  Name 

Role  Description 

Focused  on  the  Systems  Being  Developed 

Concept 

Creator 

Individual  who  holistically  explores  the  problem  or  opportunity  space  and 
develops  the  overarching  vision  for  a  system(s)  that  can  address  this  space. 

Requirements 

Owner 

Individual  who  is  responsible  for  translating  customer  requirements  to 
system  or  sub-system  requirements. 

System 

Architect 

Individual  who  owns  or  is  responsible  for  the  architectures  of  the  system; 
this  including  functional  and  physical  architectures. 

System 

Integrator 

Individual  who  provides  a  holistic  perspective  of  the  system;  this  may  be  the 
'technical  conscience'  or  'seeker  of  issues  that  fall  in  the  cracks'  - 
particularly,  someone  who  is  concerned  with  interfaces. 

System 

Analyst 

Individual  who  provides  modeling  or  analysis  support  to  system 
development  activities,  and  helps  to  ensure  that  the  system  as  designed 
meets  he  specification. 

Detailed 

Designer 

Individual  who  provides  technical  designs  that  match  the  system 
architecture;  an  individual  contributor  in  any  engineering  discipline  who 
provides  part  of  the  design  for  the  overall  system. 

V&V  Engineer 

Individual  who  plans,  conducts,  or  oversees  verification  and  validation 
activities  such  as  testing,  demonstration,  and  simulation. 

Support 

Engineer 

Individual  who  performs  the  'back  end'  of  the  systems  lifecycle,  who  may 
operate  the  system,  provide  support  during  operation,  provide  guidance  on 
maintenance,  or  help  with  disposal. 

Focus  on  Process  &  Organization 

Systems 

Engineering 

Champion 

Individual  who  promotes  the  value  of  systems  engineering  to  individuals 
outside  of  the  SE  community  -  to  project  managers,  other  engineers,  or 
management. 

Process 

Engineer 

Individual  who  defines  and  maintains  the  systems  engineering  processes  as  a 
whole  and  who  also  likely  has  direct  ties  into  the  business.  This  individual 
provides  critical  guidance  on  how  systems  engineering  should  be  conducted 
within  an  organization  context. 

Focus  on  Teams  That  Build  Systems 

Customer 

Interface 

Individual  who  coordinates  with  the  customer,  particularly  for  ensuring  that 
the  customer  understands  critical  technical  detail  and  that  a  customer's 
desires  are,  in  turn,  communicated  to  the  technical  team. 

Technical 

Manager 

Individual  who  controls  cost,  schedule,  and  resources  for  the  technical 
aspects  of  a  system;  often  someone  who  works  in  coordination  with  an 
overall  project  or  program  manager. 

Information 

Manager 

Individual  who  is  responsible  for  the  flow  of  information  during  system 
development  activities.  This  includes  the  systems  management  activities  of 
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Role  Name 


Role  Description 


configuration  management,  data  management,  or  metrics. 

Coordinator 

Individual  who  brings  together  and  brings  to  agreement  a  broad  set  of 
individuals  or  groups  who  help  to  resolve  systems  related  issues.  This  is  a 
critical  aspect  of  the  management  of  teams. 

Instructor/ 

Teacher 

Individual  who  is  provides  or  oversees  critical  instruction  on  the  systems 
engineering  discipline,  practices,  processes,  etc.  This  can  include  the 
development  or  delivery  of  training  curriculum  as  well  as  academic 
instruction  of  formal  university  courses  related  to  systems  engineering. 

Following  the  above  definitions,  the  team  identified  the  roles  performed,  in  chronological 
order,  by  systems  engineers  at  each  position.  Then,  job  descriptions  and  interviews  were 
utilized  to  capture  the  pertinent  roles  systems  engineers  executed  at  each  position.  Results 
were  then  evaluated  and  compared  among  the  multiple  seniority  levels. 

Figure  19  illustrates  the  roles  performed  by  junior  systems  engineers.  It  is  noted  that  at  position 
1  the  most  frequently  performed  roles  are  Detailed  Designer  and  V&V  Engineer.  After  position 
3,  another  major  shift  occurs.  Junior  engineers  transitioned  from  tasks  related  to  analyzing  the 
system  to  activities  necessary  to  coordinate  a  set  of  individuals.  Overall,  in  their  first  five 
positions,  junior  systems  engineers  are  more  likely  to  play  the  roles  of  System  Analyst,  Detailed 
Designer,  V&V  Engineer,  or  Coordinator.  Note  that  the  coordinator  role  for  junior  systems 
engineers  often  worked  in  one  of  two  ways:  the  individual  was  coordinating  a  small  team  on  a 
small  project  or  component  or  the  individual  was  supporting  a  senior  systems  engineer  and  one 
of  their  roles  was  to  help  with  team  coordination. 
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Junior  Systems  Engineers  -  Roles  Performed  across  Positions 


■  Position  1  ■  Position  2  ■  Position  3  ■  Position  4  Position  5 


Figure  19.  Roles  performed  by  junior  systems  engineers 

The  roles  performed  by  mid-Level  systems  engineers  are  slightly  different  at  the  beginning  of 
their  careers  compared  to  junior  engineers;  however  they  seem  to  converge  similarly  as  their 
career  progresses.  Mid-level  systems  engineers  seemed  to  have  started  their  career  performing 
verification  &  validation  activities  for  the  first  two  positions,  which  aligns  with  junior  systems 
engineers.  However,  after  position  3,  mid-level  systems  engineers  performed  the  role  of 
Coordinator  more  frequently.  Figure  20  illustrates  the  evolution  of  roles  performed  by  Mid- 
Level  systems  engineers. 
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Mid-Level  Systems  Engineers  -  Roles  Performed  across  Positions 


■  Position  1  ■  Position  2  *  Position  3  ■  Position  4  Position  5 


Figure  20.  Roles  performed  by  mid-level  systems  engineers 

Figure  21  shows  the  path  followed  by  Senior  systems  engineers  in  regard  to  the  roles 
performed  across  positions.  Senior  systems  engineers  followed  a  similar  distribution  as  the 
Junior  and  Mid-Level  systems  engineers.  Position  1  and  position  2  are  characterized  by 
performing  Verification  &  Validation  roles.  Then,  Position  3,  position  4  and  position  5  converge 
at  Coordination  roles.  A  remarkable  note  is  the  increase  and  convergence  after  position  3  to 
Technical  Manager  role.  It  is  expected  that  systems  engineers  acquire  more  technical  and 
management  responsibilities  since  their  third  position. 
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Senior  Systems  Engineers  -  Roles  Performed  across  Positions 


■  Position  1 
Figure 


■  Position  2  ■  Position  3  B  Position  4  Position  5 

21.  Roles  performed  by  senior  systems  engineers 


Interpreting  the  Results 

There  are  several  patterns  around  the  roles  of  systems  engineers  that  can  help  guide 
individuals  in  their  career  choices. 

The  most  common  role  played  in  position  1  across  seniority  levels  was  V&V  engineer.  In  almost 
all  cases,  these  individuals  started  as  testers  trying  to  verify  that  system  requirements  had  been 
met  through  a  variety  of  techniques,  often  finding  faults  and  having  to  trace  those  faults  back 
to  the  root  cause.  Many  of  them  reported  that  the  root  cause  was  often  a  failure  of 
requirements  or  of  integration  between  the  engineering  teams  -  and  thus  their  designs. 
Individuals  who  started  as  V&V  Engineers  reported  that  this  role  helped  them  to  be  better 
prepared  to  become  effectives  Detailed  Designers  and  System  Architects.  Interestingly,  junior 
and  mid-level  systems  engineers  were  more  likely  to  move  from  V&V  Engineer  into  Systems 
Analyst  than  their  senior  counterparts,  who  were  more  likely  to  continue  as  V&V  Engineers  in 
their  second  positions. 
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Another  common  early  role  is  Detailed  Designer.  This  is  unsurprising  because  it  was  common 
for  an  individual  to  work  as  a  specialty  engineer  performing  some  design  functions  at  a  lower 
level  before  becoming  a  systems  engineer. 

Several  senior  interviewees  stated  that  junior  systems  engineers  often  take  on  roles  that  cover 
only  a  small  part  of  the  life  cycle,  often  a  role  in  testing  or  requirements.  Interestingly,  though, 
it  was  more  likely  that  a  mid-level  systems  engineers  would  be  a  Requirements  Owner  in  their 
first  position  than  for  a  junior  systems  engineer.  Because  in  general  a  mid-level  systems 
engineer's  first  position  was  chronologically  early  than  a  junior  systems  engineer's,  it  is  possible 
that  this  reflects  a  change  over  time  in  the  roles  that  junior  systems  engineers  are  expected  to 
play. 

In  regards  to  leadership  and  management,  the  analysis  indicates  that  systems  engineers  started 
to  perform  leadership  and  management  positions  at  their  third  position.  For  instance,  it  was 
observed  that  the  words:  manager,  lead,  director  and  chief  were  in  the  title  of  the  positions 
occupied.  This  pattern  has  been  consistent  across  the  junior,  mid-level  and  senior  systems 
engineers. 

Roles  such  as  Customer  Interface  or  Process  Engineer  by  nature  require  more  experienced 
systems  engineers.  In  both  initial  and  follow  up  interviews,  several  senior  systems  engineers 
stated  that  it  was  critical  that  customer  interactions  be  done  by  more  senior  individuals  who 
not  only  have  a  grasp  of  the  technology  but  who  have  honed  their  communication  skills  - 
primarily  their  ability  to  translate  technical  data  for  non-technical  audiences  and  vice  versa. 
Several  of  these  individuals  stated  that  a  less  experienced  systems  engineer  simply  does  not 
have  the  ability  to  do  this  effectively.  Likewise,  senior  engineers  who  spoke  of  performing 
process  engineering  tasks  explained  that  it  required  that  the  individual  had  applied  the  process 
in  a  variety  of  contexts  and  see  where  it  was  both  successfully  and  unsuccessfully  implemented. 
It  seems  unlikely  that  junior  systems  engineers  would  have  this  breadth  of  experiences  to 
support  their  ability  to  perform  process  engineering. 


3.2.3.  System  Type 

System  type  is  refers  to  the  nature  of  the  system  of  interest.  The  Helix  team  classifies  system 
types  into:  product,  service  and  enterprise.  The  objective  is  to  identify  similarities  and 
differences  in  the  type  of  systems  junior,  mid-Level  and  senior  systems  engineers  are  exposed 
to.  Table  6  reflects  the  definition  for  each  system  typed  identified  by  Helix  team. 

Table  7.  System  type  definition  implemented  by  the  Helix  team 


Type 

Definition 

Product 

A  system  considered  from  the  point  of  view  of  a  physical  "system  end 
product"  made  of  system  elements  that  may  include  hardware,  software, 
infrastructure  and  support  services.  The  people  and  organizational  aspects  of 
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the  "whole  system"  of  which  the  "product  system"  forms  a  part  have  to  be 
considered  in  the  design,  but  are  provided  by  another  organization. 

Service 

A  dynamic  configuration  of  resources  (people,  technology,  organizations  and 
shared  information)  that  creates  and  delivers  value  between  the  provider  and 
the  customer  through  services. 

Enterprise 

A  complex,  (adaptive)  socio-technical  system  that  comprises  interdependent 
resources  of  people,  processes,  information,  and  technology  that  must 
interact  with  each  other  and  their  environment  in  support  of  a  common 
mission  to  offer  an  output  such  as  a  product  or  service. 

Following  the  definitions  of  Table  5,  the  team  identified  the  roles  performed,  in  chronological 
order,  by  systems  engineers  at  each  position.  Then,  job  descriptions  and  interviews  were 
utilized  to  capture  the  pertinent  system  types  systems  engineers  were  involved  to.  Results  were 
then  evaluated  and  compared  among  the  multiple  seniority  levels. 


Figure  22  shows  a  comparison  between  seniority  level  and  system  type.  It  is  interesting  that 
100%  of  junior  systems  engineers  started  their  career  by  focusing  on  product  systems  in  both 
their  first  and  second  positions.  While  the  majority  of  mid-level  and  senior  systems  engineers 
also  started  working  on  product  systems,  a  small  number  did  work  on  services  or  enterprises. 
This  could  reflect  the  participating  organizations,  which  were  mainly  product-focused. 

Junior  systems  engineers  eventually  transitioned  to  service  and  enterprise-type  of  systems. 
Mid-Level  and  senior  engineers  seemed  to  have  more  diversity  in  regard  to  system  types. 
Senior  engineers  seemed  to  start  their  career  focusing  on  product  and  occasionally  service 
systems,  but  as  their  careers  progressed,  small  increments  of  enterprise  systems  occurred  until 
more  than  20%  of  them  were  focused  at  the  enterprise  level.  This  kind  of  growth  in  scope  is  not 
necessarily  surprising,  but  it  is  interesting  to  note  that,  overall,  product  systems  dominate  and 
service  or  enterprise  systems  are  less  common.  Again,  this  may  represent  bias  in  the  Helix 
sample. 
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Comparison  of  System  Type  by  Seniority  Level  and  Position 


100% 
80% 
ra  60% 


£  40% 

0) 

Q_ 


20% 

0% 


c 


il 


>  .2 

a)  'c 

^  $ 


C 

13 


il 


>  .2 

cu  ’c 

^  $ 


C 

3 


J 


>  .2 

a)  'c 

^  $ 


J 


o  goo  >  .9 

'c  Ol  c  ‘c  Ol  'c 

O  =  Ol  3  =  Ol 

— -  2  i/i  — >  ^9  c/i 


Position  1  Position  2  Position  3  Position  4 

■  Product  ■  Service  ■  Enterprise 


Position  5 


Figure  22.  Comparison  of  system  type  and  seniority  level 
Interpreting  the  Results 

It  is  important  not  to  over-interpret  the  results  of  the  system  type  analysis.  As  stated  above,  it  is 
possible  that  sampling  bias  is  responsible  for  the  heavy  presence  of  product  systems  in  the 
experiences  of  the  systems  engineers  in  the  Helix  sample.  It  is  also  possible  that,  in  general, 
organizations  which  focus  on  product  systems  are  more  likely  to  think  about  systems 
engineering  as  a  separate  discipline  and,  therefore,  participate  in  the  study. 

The  only  clear  pattern  here  is  that  it  is  unlikely  that  a  junior  systems  engineer  will  be  asked  to 
work  on  service  or  enterprise  systems.  As  these  are  generally  considered  more  complex  than 
enterprise  systems,  this  seems  reasonable. 


3.2.4.  System  Scope 

System  scope  defines  level  of  abstraction  where  the  systems  engineers  are  performing  their 
activities.  Table  8  describes  the  system  levels  identified  by  Helix.  These  include  component, 
sub-system,  system  and  platform  or  system  of  systems. 

To  determine  the  level  of  exposure  to  a  system  by  an  individual's  systems  engineer,  the  team 
first  identified  the  positions  in  chronological  order.  Then,  job  descriptions  and  interviews  were 
utilized  to  capture  the  pertinent  system  scope  systems  engineers  were  involved  to.  Results 
were  then  evaluated  and  compared  among  the  multiple  seniority  levels. 
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Table  8.  Definition  of  system  scope  levels 


Level 

Definition 

Component 

An  entity  with  discrete  structure,  such  as  an  assembly  or  software 
module,  within  a  system  considered  at  a  particular  level  of  analysis. 

Subsystem 

A  self-contained  system  within  a  larger  system. 

System 

A  self-contained  combination  of  interacting  components  organized  to 
achieve  one  or  more  stated  purposes. 

Platform  / 
Systems  of  Systems 

Two  or  more  systems  that  are  separately  defined  but  together  can 
perform  a  common  goal. 

Figure  23  illustrates  that  junior  systems  engineers  commonly  start  their  careers  at  the 
component  level.  As  their  careers  advance,  they  are  exposed  to  the  sub-system  or  system  level. 
Mid-level  systems  engineers  show  more  diversity  by  starting  at  the  component,  sub-system  and 
system  level.  Once  they  move  up  in  their  careers  they  get  exposure  to  platform/system  of 
systems.  Most  senior  systems  engineers  started  focusing  at  the  component  level  but  began 
working  at  the  sub-system  and  system  level.  Through  their  career.  Senior  systems  engineers 
have  exposure  to  all  system  levels. 


Comparison  of  System  Scope  by  Seniority  Level  and  Position 


■  Component  ■Sub-System  ■  System  ■  Platform  /  System  of  Systems 


Figure  23.  Comparison  of  system  scope  and  seniority  level 


Interpreting  the  Results 

Here  the  Helix  data  follows  the  patterns  anticipated  by  the  Helix  team  and  described  by  almost 
all  interviewees:  systems  engineers  tend  to  start  on  small-scale  areas,  particularly  in  system 
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components,  and  their  work  grows  in  scope  over  timer.  I  was  uncommon  for  individuals  to  start 
working  in  a  subsystem  or  system,  but  systems  engineers  tend  to  move  up  to  the  next  level  of 
system  as  they  change  positions.  Many  systems  engineers  described  this  as  "the  right  way"  to 
grow,  stating  that  junior  systems  engineers  need  to  grow  build  skills  and  a  foundation  of 
understanding  at  the  component  level  and  then  expand  that  scope  over  time.  However,  there 
are  examples  of  systems  engineers  who  started  their  work  at  the  subsystem  or  system  level  and 
reported  that  being  able  to  "see  the  big  picture"  at  this  level  was  very  helpful,  even  though  they 
were  new,  and  helped  them  become  better  integrators. 


3.2.5.  Keyword  and  Cluster  Analysis 

To  visualize  change  in  position  titles.  Helix  team  recurred  to  Natural  Language  Processing 
techniques.  First,  position  titles  for  each  position  and  each  seniority  level  where  pasted  in  a 
new  document.  Then,  a  term  frequency-inverse  document  frequency  (tf-idf)  method  was 
utilized  to  obtain  the  most  important  term  in  the  document  (Salton  and  Buckley,  1988).  Tf-idf 
has  been  utilized  in  information  retrieval  by  selecting  features  in  a  collection  of  documents  or 
corpus  and  analyzing  the  word  frequency.  The  team  implemented  the  td-idf  method  to  create 
wordclouds,  a  visualization  method  that  correlates  word  frequency  with  word  size.  For  this 
task,  the  team  omitted  the  words  "systems",  "engineering"  and  "engineer"  due  to  the  fact  that 
they  were  the  most  frequent  in  each  position.  Since,  the  main  goal  is  to  discover  patterns,  by 
omitting  the  most  frequent  words,  patterns  emerged  from  the  data. 

Figure  24  illustrates  the  most  frequent  position  titles  for  junior  systems  engineers  by 
chronological  position.  It  can  be  noted  that  at  position  1,  junior  systems  engineers  performed 
apprenticeship  technical  position  such  as  student  intern  and  research  assistant.  At  position  2 
and  on,  systems  engineers  transition  to  technical  position. 

Only  four  positions  for  are  mapped  for  junior  systems  engineers  as  the  majority  of  junior 
systems  engineers  have  held  four  positions  or  fewer. 
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Position  Titles  for  Junior  Systems  Engineers 
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Figure  24.  Most  frequent  position  titles  for  junior  systems  engineers 


Figure  25  depicts  the  most  frequent  position  titles  for  mid-Level  systems  engineers  by 
chronological  position.  Mid-Level  engineers  started  their  career  in  the  technical  area.  Then,  at 
position  3  is  when  more  formal  leadership  positions  are  performed.  It  can  be  noted  that  some 
titles  include  the  word  "senior",  however  they  have  not  considered  senior  systems  engineer 
since  they  do  not  meet  the  Helix  criteria  presented  in  Table  1.  Also,  due  to  the  sample 
population  of  mid-Level  engineers  position  6  has  low  frequency  of  words,  meaning  only  in  few 
instances  mid-Level  systems  engineers  performed  six  positions. 
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Position  Titles  for  Mid-Level  Systems  Engineers 
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Figure  25.  Most  frequent  position  titles  for  mid-level  systems  engineers 


Figure  26  illustrates  the  most  frequent  position  titles  for  senior  systems  engineers.  In  a  similar 
pattern  to  junior  and  mid-level  engineers,  senior  systems  engineers,  play  technical  roles  at  their 
first  position.  Also,  at  position  3  the  word  "manager"  gains  significant  weight.  In  contrast  to 
other  seniority  levels,  senior  systems  engineers  start  using  the  word  "Chief"  in  their  position 
titles  at  position  4.  Then,  it  can  be  noted  that  senior  engineers  hold  managerial  and  lead 
positions. 
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Position  Titles  for  Senior  Systems  Engineers 
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Figure  26.  Most  frequent  position  titles  for  senior  systems  engineers 


Previous  examples  illustrate  how  text  mining  algorithms  might  be  used  to  identify  similarities  in 
position  titles  for  systems  engineers.  In  broad  terms,  organizations  recruit  systems  engineers 
for  their  technical  skills  as  seen  in  the  first  position  for  junior,  mid-level  and  senior  systems 
engineers.  Then,  the  third  position  is  another  benchmark  for  systems  engineers  when  they 
acquire  management  responsibilities. 

The  next  career  pattern  covers  organizational  career  paths  for  systems  engineers.  It  discusses 
the  multiple  fields  where  engineers  have  spent  their  careers  and  also  the  job  mobility  of  junior, 
mid-level  and  senior  systems  engineers. 


3.3.  Organizations 

In  terms  of  individual  experiences,  it  is  useful  to  understand  the  domain  where  a  systems 
engineer  has  developed  his  skills.  Helix  classified  organizations  into  government,  industry,  or 
academic  organizations,  or  a  combination  of  these. 
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In  general,  government  systems  engineers  tend  to  oversee  work  done  by  systems  engineers  in 
industry  as  opposed  to  having  the  same  direct  responsibility  for  a  system  as  seen  in  industry. 

The  different  types  of  positions  in  the  different  sectors  provide  opportunities  to  develop  new 
proficiencies  -  perhaps  in  new  domains  or  operational  contexts,  or  perhaps  in  new  ways  that 
systems  engineering  would  be  applied.  However,  some  individuals  stated  that  it  might  be 
difficult  to  transition  between  sectors  because  the  overall  ways  in  which  the  organizations 
operate,  the  processes  used,  and  the  cultures  embedded,  may  be  nearly  polar  opposites.  This 
may  mean  that  some  skills  become  either  obsolete  or  even  harmful  in  a  new  organizational 
sector.  Moving  across  organizational  sectors  provides  the  opportunity  to  build  new 
proficiencies.  While  this  may  be  true  for  movement  between  any  organizations,  interviewees 
indicated  that  the  impact  is  significant  when  moving  between  organizations  in  different  sectors. 

To  determine  the  type  of  organizations  systems  engineers  develop  their  skills,  the  team  first 
identified  the  positions  in  chronological  order.  Then,  job  descriptions  and  interviews  were 
utilized  to  capture  the  pertinent  organizations.  Results  were  then  evaluated  and  compared 
among  the  multiple  seniority  levels. 

Figure  27  shows  the  distribution  of  the  organizational  sectors  that  Helix  interviewees  have 
worked  in  so  far  during  their  systems  engineering  relevant  careers. 


Organizational  Experience  by  Seniority 
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Figure  27.  Organization  domain  and  systems  engineer  experience 

As  it  can  be  observed,  government  and  industry  organizations  cover  more  than  90%  of  the 
organizations  where  junior,  mid-level  and  senior  systems  engineers  perform  their  activities. 
Only  in  few  instances  systems  engineers  have  affiliation  to  an  academic  institution. 
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When  an  individual  works  within  a  single  organization  for  a  long  period  of  time,  he  or  she  learns 
and  internalizes  the  organization's  processes  for  systems  engineering,  builds  a  network  of  peers 
that  they  leverage  to  better  perform  systems  engineering,  and  how  to  operate  within  the 
organization.  All  of  these  factors  contribute  to  a  systems  engineer's  proficiency  and 
effectiveness.  However,  moving  to  a  new  organization  provides  opportunities  for  gaining  new 
proficiencies.  Exposure  to  different  processes  or  systems  engineering  approaches  helps  systems 
engineers  better  understand  the  conditions  appropriate  to  different  approaches,  and  improves 
their  ability  to  tailor  processes  and  approaches  as  appropriate.  Working  within  a  new  culture 
provides  opportunities  to  better  understand  the  impacts  of  culture  on  the  overall  effectiveness 
of  systems  engineers.  Though  transitions  might  be  difficult,  they  can  provide  valuable 
experiences. 

Figure  28  shows  the  distribution  of  total  number  of  organizations  worked  across  the  sample, 
divided  by  seniority. 

Comparison  of  Number  of  Organizations  by  Seniority  Level 
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Figure  28.  Distribution  of  number  of  organizations  by  seniority  level 

Junior,  mid-level,  and  senior  systems  engineers  predominantly  worked  in  six  or  fewer 
organizations.  More  than  40%  of  the  junior  systems  engineers  have  worked  in  only  one 
organization,  as  their  careers  have  been  generally  much  shorter.  Over  30%  of  mid-level  systems 
engineers  and  over  20%  of  senior  systems  engineers  have  only  worked  within  a  single 
organization.  Those  who  fall  within  this  category  explained  that  they  understood  the 
organizational  context  so  well  and  are  satisfied  with  that  context,  that  they  see  no  need  to 
make  changes.  Lastly,  only  the  most  senior  systems  engineers  in  the  sample  have  worked  in  8 
or  more  organizations,  as  they  generally  have  had  the  longest  careers  and,  therefore,  the  most 
opportunities  for  movement  between  organizations. 
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4.  Career  Paths  of  Chief  Systems  Engineers 


A  chief  systems  engineer  (CSE)  has  formal  responsibility  to  oversee  and 
shepherd  the  technical  correctness  of  a  system,  often  coordinating  with 
many  other  engineers  who  have  smaller  scopes  of  responsibility.  In 
many  organizations,  the  CSE  (or  equivalent)  is  the  highest  technical 
position  a  systems  engineer  can  play. 

In  both  the  Helix  dataset  and  the  INCOSE  dataset,  the  Helix  team 
identified  individuals  considered  "chief  systems  engineers",  regardless 
of  their  actual  titles.  In  Helix,  these  are  labeled  CSEs.  In  the  INCOSE 
dataset,  the  Helix  team  identified  individuals  who  fulfilled  the 
description  of  a  chief  systems  engineer.  There  were  many  different 
titles  associated  with  them.  To  distinguish  between  the  Helix  and 
INCOSE  datasets,  INCOSE  CSE  equivalents  are  called  "ChiefX". 

Because  CSEs  and  ChiefXs  were  the  most  senior  technical  systems  engineers  in  the  samples, 
they  provide  examples  of  individuals  who  have  successfully  grown  to  become  the  most  trusted 
and  respected  systems  engineers  in  their  organizations.  The  Helix  team,  therefore,  believes  that 
examining  the  career  paths  of  CSEs  and  ChiefXs  may  provide  some  insights  into  how  these 
individuals  became  so  effective. 


CSE  -  term  used  to 
identify  a  chief 
systems  engineer 
equivalent  in  the 
Helix  dataset. 

ChiefX  -  term  used 
to  identify  a  chief 
systems  engineer 
equivalent  in  the 
INCOSE  dataset. 


4.1.  Examining  the  Career  of  Chief  Systems  Engineers  (CSEs) 

The  description  of  a  career  path  is  only  useful  to  the  extent  that  it  provides  valuable  insights 
about  how  individual  systems  engineers  can  grow,  mature,  and  develop  their  own  careers.  But 
what  are  the  paths  that  lead  to  success?  From  the  Helix  interview  data,  a  Chief  Systems 
Engineer  (CSE)  is  one  of  the  most  senior  technical  positions  that  a  systems  engineer  can 
achieve.  Individuals  who  became  CSEs  were  able  to  do  so  because  they  had  proven  themselves 
to  be  effective  throughout  their  careers,  and  had  continually  demonstrated  the  ability  to  take 
on  increasing  responsibilities.  Hence,  Helix  considers  the  careers  of  CSEs  worthy  of  further 
examination,  since  it  can  provide  valuable  insights  to  systems  engineers  early  in  their  career  to 
be  develop  into  CSEs  in  future. 

Helix  identified  27  individuals  in  the  interview  sample  who  currently  hold  or  have  held  the  CSE 
position,  for  further  analysis.  Though  many  aspects  of  education  and  experiences  were 
explored,  a  select  few  which  provided  particularly  strong  impacts  on  proficiency  are  discussed 
here:  overall  educational  background;  experiences  across  systems  engineering  lifecycle  phases; 
and  experiences  across  systems  engineering  roles. 

In  addition,  there  was  a  wealth  of  information  available  from  the  INCOSE  SEP  applications, 
especially  on  individuals  applying  for  Expert  Systems  Engineering  Professional  (ESEP) 
certification.  That  information  from  INCOSE  SEP  data  was  also  analyzed  by  Helix. 
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4.1.1.  Educational  Background  of  CSEs 


Each  CSE  in  the  sample  had  a  bachelor's  degree;  for  18%  of  interviewees,  this  was  the  highest 
degree  attained.  Around  82  %  of  CSEs  held  at  least  one  master's  degree  and  15%  held  a  PhD. 
The  most  common  bachelor's  degrees  majors  among  CSEs  include  Electrical  Engineering  and 
Mechanical  Engineering  covering  more  than  two-thirds  of  the  CSE  dataset.  Figure  30  illustrate 
the  distribution  of  bachelor's  degrees  majors  pursued  by  CSE's. 


Bachelor's  Degree  Majors  of  CSE's 
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Figure  29.  Distribution  of  bachelor's  degrees  across  CSE's 

In  regard  to  master's  degrees.  Masters  of  Business  Administration  (MBA)  is  the  most  popular 
major  covering  almost  50%  of  the  dataset.  It  is  followed  by  systems  engineering  and  electrical 
engineering  respectively.  Figure  30  illustrates  the  distribution  of  master's  degrees  attained  by 
CSEs. 
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Figure  30.  Distribution  of  master's  degrees  across  CSE's 
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The  following  observations  can  be  made  from  Figure  29  and  Figure  30: 

•  85%  of  CSEs  have  bachelor's  education  in  engineering  fields;  a  small  number  were 
educated  in  the  physical  sciences,  mathematics,  or  business  (<5%  of  each). 

•  Bachelor's  education  in  systems  engineering  was  also  seen  in  less  than  5%  of  CSEs.  It 
was  very  common  in  the  overall  Helix  sample  for  systems  engineers  to  start  out  in 
specialty  engineering  fields,  and  the  educational  backgrounds  of  CSEs  indicate  that  this 
was  true  for  them  as  well. 

•  In  general,  engineering  bachelor's  education  prepared  CSEs  with  sufficient  proficiency  in 
Math/Science/General  Engineering  to  perform  detailed  design  work,  do  detailed 
analysis,  or  support  test  and  evaluation. 

•  Only  7%  of  the  CSEs  have  a  master's  degree  in  systems  engineering;  this  is  considerably 
lower  than  the  overall  rate  of  systems  engineering  graduate  degrees  in  the  total  Helix 
sample  (26%). 

•  Most  CSEs  indicated  that  they  believed  their  experiences  were  sufficient  and  they  did 
not  believe  that  they  would  benefit  enough  to  warrant  the  effort  required  to  earn  a 
master's  degree  in  systems  engineering. 

•  About  a  third  of  CSE's  master's  degrees  (39%)  were  in  engineering  fields  outside  of 
systems  engineering;  this  similar  slightly  higher  compared  to  what  is  seen  among  other 
senior  systems  engineers  in  the  sample  (34  %). 

•  The  most  common  master's  field  among  CSEs  was  related  to  business  (48%);  generally, 
these  were  MBA  degrees,  though  occasionally  they  were  master's  of  science  degrees 
related  to  more  technical  fields  such  as  technology  management.  The  CSEs  with  these 
degrees  explained  that  they  felt  they  had  sufficient  technical  understanding  but  needed 
to  learn  more  about  business,  management,  finance,  and  other  disciplines  that  support 
understanding  business  processes. 

•  The  most  common  PhD  concentration  in  the  overall  sample  was  systems  engineering, 
but  there  is  no  single  common  field  of  doctoral  study  among  CSEs;  electrical 
engineering,  geotechnical  engineering,  and  atmospheric  sciences  have  equal 
representation.  Doctoral  studies  were  not  required  for  advancement  for  any  of  the 
CSEs.  Instead,  those  with  PhDs  indicated  their  continued  desire  to  learn  and  grow  and 
improve  their  understanding  of  specific  disciplines  was  their  motivation. 


4.1.2. Experiences  across  Systems  Engineering  Roles  for  CSEs 

All  of  the  CSEs  in  the  sample  have  experiences  across  either  four  or  five  lifecycle  phases,  but 
none  of  the  CSEs  have  experienced  all  six  of  the  lifecycle  phases.  Figure  31  provides  insight  into 
the  order  in  which  CSEs  experienced  the  systems  lifecycle. 
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CSE  Experiences  across  the  System  Lifecycle 
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Figure  31.  Order  of  Exposure  to  Lifecycle  Phases  Experienced  by  CSEs 


There  were  a  few  clear  patterns  in  how  CSEs  moved  through  the  systems  lifecycle: 

•  All  CSEs  have  experienced  System  Definition,  System  Realization,  and  Systems 
Engineering  Management. 

•  The  most  common  point  of  entry  for  CSEs  was  System  Definition;  it  was  either  the  first 
or  second  aspect  of  the  lifecycle  experienced  by  74%  of  CSEs.  The  most  common 
pathway  for  entry  into  systems  related  work  was  through  work  as  a  specialty  engineer. 
This  detailed  work  was  necessary  to  gain  some  depth  -  to  understand  how  things  "really 
work"  and  the  problems  that  can  be  encountered  when  they  try  to  design  something. 
These  Experiences  impact  the  Math/Science/General  Engineering  and  System's  Domain 
and  Operational  Context  proficiency  areas.  Also,  many  CSEs  experienced  leading  design 
work  early  in  their  careers,  which  would  improve  the  Technical  Leadership  and 
Interpersonal  Skills  proficiency  areas.  It  is  worth  noting  that  this  parallels  the  patterns 
seen  in  among  other  senior  systems  engineers  -  so  appears  to  be  more  of  a  trend  of  the 
experiences  of  systems  engineers  over  a  specific  period  of  time  (generally,  10-20  years 
ago)  than  a  differentiator  for  CSEs. 

•  83%  of  the  CSEs  had  experienced  System  Realization.  Systems  engineers  who  had 
experience  in  manufacturing,  which  falls  into  System  Realization,  explained  that  these 
Experiences  are  valuable  because  they  help  engineers  understand  the  practical 
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considerations  and  issues  of  implementing  a  design.  Understanding  the  basic  constraints 
on  the  common  manufacturing  techniques  was  stated  as  very  valuable  in  improving 
design  work  and  limiting  the  need  for  redesign. 

•  For  Systems  Engineering  Management,  all  CSEs  in  the  sample  were  also  Technical 
Managers.  The  related  activities:  planning,  configuration  management,  decision 
management,  etc.  are  all  part  of  the  CSE  position.  In  general,  these  types  of  activities 
were  reported  to  help  in  the  development  of  Technical  Leadership,  Interpersonal  Skills, 
and  Systems  Engineering  Discipline  proficiencies. 

•  Concept  Definition  includes  working  directly  with  stakeholders  to  identify  the  problem 
and  "true  needs"  (as  opposed  to  a  stakeholder's  assumptions  about  the  right  type  of 
solution).  Gaining  this  type  of  understanding  first-hand  gives  systems  engineers  the 
opportunity  to  improve  their  understanding  of  the  vision  for  the  system  and  how  it  will 
be  used,  supporting  growth  in  System's  Domain  and  Operational  Concept  and  Systems 
Engineering  Mi ndset  proficiencies.  Communicating  directly  with  customers  also  enables 
systems  engineers  to  build  their  skills  not  just  in  general  communication,  but  also  in  the 
translation  of  non-technical  information  for  a  technical  audience  and  vice  versa.  This 
provides  an  opportunity  for  improving  Interpersonal  Skills  proficiencies.  The  majority  of 
CSEs  have  had  these  Experiences  -  and  often  fairly  early  in  their  careers  -helping  them 
grow  as  systems  engineers. 

•  Among  CSEs,  60%  of  those  who  started  in  System  Deployment  and  Use  gained 
experience  in  the  operation  and  maintenance  of  relevant  systems  as  members  of  the  US 
military.  The  remaining  40%  also  worked  as  operators  and  maintainers,  but  working  in 
industry.  Through  these  Experiences,  CSEs  had  the  opportunity  to  understand  how  a 
system  should  operate,  what  the  common  processes  and  procedures  were  in  relation  to 
a  system,  and  to  understand  the  problems  that  existing  systems  have.  All  of  these 
activities  provided  opportunities  to  improve  the  systems  engineer's  System's  Domain 
and  Operational  Concept  proficiency.  They  also  provide  key  insights  about  the  overall 
lifecycle  of  a  system,  which  can  improve  Systems  Engineering  Discipline  proficiency.  All 
of  the  CSEs  who  began  their  careers  in  System  Deployment  and  Use  stated  that  the 
understanding  of  issues  that  can  lead  to  maintenance  problems  and  issues  encountered 
with  operating  these  systems  such  as  counterintuitive  interfaces  gave  them  better 
insights  when  they  eventually  began  doing  design  work.  These  insights  better  enabled 
them  to  do  technical  tradeoffs  and  also  helped  them  to  better  understand  the 
importance  of  working  through  a  systems  concept  of  operations  (CONOPS)  early  in  the 
design  phase.  These  Experiences,  then,  can  improve  their  proficiencies  in  System's 
Domain  and  Operational  Concept  and  Systems  Engineering  Mindset  ( Abstraction  and 
Foresight),  as  well  providing  specific  insights  into  lifecycle  considerations  for  Systems 
Engineering  Discipline. 

•  No  matter  where  they  started  in  the  systems  lifecycle,  CSEs  cited  benefits  in  later  phases 
they  experienced.  For  example,  CSEs  starting  in  testing  (System  Realization,  13%)  stated 
they  gained  insights  into  the  unintended  consequences  of  certain  design  decisions  and 
these  insights  helped  them  avoid  some  of  these  pitfalls  when  they  began  design  work 
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(System  Definition).  Starting  in  Concept  Definition  -  working  on  stakeholder  needs  and 
CONOPS  -  provided  an  opportunity  to  better  understand  the  "end  state"  or  "big 
picture"  -  and  this  helped  keep  the  system  goals  in  mind  during  the  design  process. 

In  the  sample  of  CSEs,  there  do  not  seem  to  be  standard  patterns  to  move  through  the  systems 
engineering  lifecycle,  except  that  starting  in  System  Design  is  most  common  and  those  who  do 
not  start  in  system  design  most  commonly  next  move  into  System  Design.  The  order  seems  less 
critical  than  having  a  mixture  of  experiences  across  the  lifecycle  and  having  a  mindset  that 
enables  systems  engineers  to  draw  connections  across  these  experiences  to  enable 
understanding  and  growth. 


4.1.3.  Experiences  across  Systems  Engineering  Roles  for  CSEs 

There  are  multiple  types  of  roles  that  systems  engineers  can  play  within  a  single  position  or 
even  a  single  phase  of  the  systems  lifecycle.  To  better  understand  how  individuals  grew  into 
their  CSE  positions,  the  roles  played  by  CSEs  in  the  Helix  sample  prior  to  their  first  CSE  position, 
and  during  their  first  CSE  position  were  analyzed.  All  roles  played  by  CSEs  throughout  their 
careers,  up  to  the  point  of  their  participation  in  Helix  interviews,  were  also  analyzed.  The 
reason  this  is  important  is  this  illustrates  the  roles  of  the  career  paths  leading  up  to  becoming  a 
CSE,  which  can  provide  critical  examples  for  systems  engineers  hoping  to  grow  into  CSEs. 


Roles  Played  Prior  to  First  Chief  Systems  Engineering  Position 

Figure  32  provides  an  overview  of  the  roles  played  by  CSEs  prior  to  their  first  CSE  position,  to 
provide  insight  into  the  career  paths  that  helped  these  individuals  become  CSEs.  This  has  been 
updated  to  reflect  the  Atlas  1.1  role  framework.  Note  that  the  roles  of  Concept  Creator, 
Detailed  Designer,  and  Systems  Engineering  Champion  are  not  included  in  the  analysis.  This  is 
because  data  on  these  roles  was  not  collected  consistently  throughout  the  sample;  additional 
follow  up  will  be  required  to  enable  analysis  for  these  roles. 
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Figure  32.  Roles  Played  by  CSEs  Prior  to  Their  First  CSE  Position 

Insights  from  analyzing  the  roles  played  by  CSEs  prior  to  their  first  CSE  position  include: 

•  All  of  the  systems  engineers  who  would  become  CSEs  worked  as  System  Designers  and 
Technical  Managers  prior  to  their  first  CSE  position.  As  discussed  earlier,  these  roles  are 
generally  a  critical  aspect  of  the  CSE  position,  so  it  is  reasonable  that  individuals  would 
have  to  prove  their  abilities  in  other  roles  prior  to  being  offered  a  CSE  position. 

•  The  less  common  roles  (50%  or  lower)  are  Process  Engineer,  Organizational  Manager, 
and  Program/Project  Manager.  It  is  possible  that  CSEs  did  work  in  these  areas,  but  this 
simply  did  not  make  it  into  their  descriptions  or  discussions  of  the  positions  they've 
played. 

•  The  roles  of  Instructor/Teacher,  and  Program/Project  Manager  are  generally  less 
common  in  the  Helix  sample  (21%,  and  19%,  respectively).  The  rates  among  CSEs  are 
more  than  twice  that  seen  in  the  general  sample. 

•  One  CSE  stated  that  he  had  performed  the  Organizational  Manager  role  as  a  favor  to 
the  organization  -  to  fill  a  role  that  was  needed  as  an  interim  measure  -  but  with  the 
expectation  that  he  would  then  pursue  a  technical  track.  Other  CSEs  explained  that  in 
their  organizations,  spending  some  time  as  an  Organizational  Manager  is  a  requirement 
before  one  can  become  a  CSE.  Time  spent  as  an  Organizational  Manager  primarily 
provides  insights  into  the  functioning  of  the  organization,  and  may  also  provide  some 
insight  into  processes  and  opportunities  to  grow  a  network  of  experts  within  an 
organization,  corresponding  with  growing  proficiencies  in  Technical  Leadership. 

•  Over  a  quarter  of  the  CSEs  have  been  instructors  of  in-house  training  or  professors  at 
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universities  focusing  on  teaching  systems  engineering  or  related  subjects.  These  roles 
improve  proficiency  in  the  subject  matter  not  just  through  the  creation  of  course 
materials  but  also  through  interactions  with  the  students  and  the  application  of  real- 
world  Experiences  in  an  academic  setting. 

•  The  role  of  Program/Project  Manager  has  been  played  by  nearly  half  the  CSEs  prior  to 
their  first  CSE  position,  as  in  many  organizations  the  PM  role  was  considered  a  role  with 
higher  responsibility  than  that  of  CSE.  In  these  cases,  the  CSE  acted  as  a  Program/Project 
Manager  on  a  smaller  or  less  complex  system  before  taking  on  CSE  positions  on  a  larger 
and/or  more  complex  system.  CSEs  explained  that  playing  this  role  helped  them  to 
better  understand  not  just  the  technical  constraints  of  a  system,  but  also  to  build  an 
appreciation  for  schedule,  budgetary,  and  resource  constraints  as  well  as  the  overall 
business  case  for  systems  development,  and  also  provided  the  opportunity  to 
understand  the  customer's  perspective  in  a  different  way.  This  role  was  particularly 
strong  in  helping  develop  proficiency  in  the  Technical  Leadership  area. 

The  final  aspect  of  the  roles  of  systems  engineers  is  more  general  than  Sheard's  twelve  roles 
(1996)  and  that  is  the  overarching  concept  of  leadership.  Each  CSE  described  having  several 
leadership  positions  early  in  their  careers,  starting  generally  as  small  group  leaders  on  simple 
tasks  and  continually  taking  on  increasing  leadership  roles  throughout  their  careers.  Several  of 
the  systems  engineering  roles  described  above  may  have  a  distinct  leadership  component.  For 
example,  a  Reguirements  Owner  may  start  by  simply  recording  requirements  in  a  database, 
progress  to  leading  a  small  team  to  manage  the  database,  then  progress  to  having  responsibility 
for  coordinating  with  the  customer  (adding  the  Customer  Interface  role)  to  generate  the  best 
set  of  requirements  while  overseeing  the  team  that  manages  the  requirements.  These  types  of 
patterns  -  with  leadership  responsibilities  even  in  more  detail-oriented  roles  -  is  a  common 
pattern  for  CSEs,  indicating  that  it  is  through  leadership  activities  that  systems  engineers  can 
provide  their  greatest  value. 


Role  Played  during  First  Chief  Systems  Engineering  Position 

If  someone  wants  to  become  a  CSE,  what  does  that  really  mean?  The  Helix  team  examined  the 
roles  in  the  descriptions  of  the  each  first  CSE  position  from  resumes  and  interview  data,  and 
their  commonality  within  the  sample  of  CSEs,  as  shown  in  Figure  33.  These  descriptions  provide 
insight  into  what  it  commonly  means  in  the  systems  engineering  community  to  be  a  CSE.  Note 
that  the  roles  of  Concept  Creator,  Detailed  Designer  and  Systems  Engineering  Champion  are  not 
included;  this  is  because  the  data  on  these  roles  was  not  collected  consistently  and  additional 
follow  up  will  be  required. 
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Roles  Played  During  the  First  CSE  Position 
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Figure  33.  Roles  Played  by  CSEs  During  Their  First  CSE  Position 


Insights  from  analyzing  the  roles  played  by  CSEs  during  their  first  CSE  position  include: 

•  All  of  the  CSEs  describe  the  role  of  Technical  Manager  as  a  part  of  the  CSE  position,  and 
95%  described  the  role  of  Coordinator  as  another  critical  aspect  of  the  position.  Over 
3/4  of  CSEs  have  had  a  critical  role  as  Technical  Manager  and  Coordinator  as  part  of 
their  first  CSE  position.  One  CSE  explained  that  the  variety  of  roles  played  in  the  CSE 
position  is  somewhat  dependent  on  the  organization.  For  example,  when  he  was  a  CSE 
at  a  small  organization,  he  had  to  be  a  "jack  of  all  trades"  and  therefore  played  a 
multitude  of  roles;  now  at  a  much  larger  organization,  his  role  of  CSE  is  more  specialized 
because  there  are  more  people  available  to  perform  other  roles.  Both,  he  explained, 
had  benefits  for  development  of  systems  engineering  related  skills. 

•  The  more  detail-oriented  roles  were  less  commonly  seen  as  part  of  the  CSE  position,  but 
did  occur.  Often,  when  a  role  was  not  directly  performed  by  the  CSE,  interviewees 
explained  that  the  role  was  simply  performed  by  a  member  of  the  team  and  overseen 
by  the  CSE. 

•  It  is  also  rare  for  a  CSE  to  function  as  a  Program/Project  Manager.  In  the  instances 
where  this  did  occur,  it  was  generally  on  a  smaller  project,  where  the  overall  smaller 
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staff  required  that  single  individuals  take  on  multiple  positions. 

•  Organizational  Manager  is  again  a  very  uncommon  role  for  a  first  CSE  position,  as  the 
focus  for  CSEs  is  generally  technical  over  administrative. 

•  None  of  the  CSEs  had  detailed  V&V  responsibilities  in  their  initial  CSE  roles  because  the 
CSE  must  oversee  a  team  of  systems  engineers  and  other  engineers.  Occasionally  a  CSE 
would  play  the  role  of  subject  matter  expert  or  detailed  designer  in  a  CSE  position,  but 
this  always  occurred  much  later  in  their  careers,  often  as  part  of  a  smaller  project  or  a 
proposal. 

The  roles  played  in  a  first  CSE  position  would  tend  to  further  proficiencies  in  System's  Domain 
and  Operational  Context,  Systems  Engineering  Discipline,  Systems  Engineering  Mindset, 
Interpersonal  Skills,  and  Technical  Leadership.  Though  a  CSE  may  not  lose  skills  in 
Math/Science/General  Engineering,  however,  because  the  role(s)  played  seldom  focus  on  these 
areas,  it  would  be  unlikely  for  a  CSE  to  gain  proficiency  in  these  areas. 


Roles  Played  throughout  CSEs'  Careers 

Figure  34  provides  an  overview  of  the  roles  played  by  CSEs  throughout  their  careers,  spanning 
up  to  their  participation  in  Helix. 

Frequency  of  Roles  Played  by  CSE's 


100% 

90% 

80% 


Roles 


Figure  34.  Roles  Played  by  CSEs  Throughout  Their  Whole  Careers 
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The  following  observations  can  be  made  from  Figure  34: 

•  Most  frequent  roles  among  CSEs  in  the  Helix  sample  include  Technical  Manager  (92%), 
Coordinator  (88%),  Requirements  Owner  (79%)  and  Detailed  Designer  (79%). 

•  Even  in  areas  where  less  than  100%  of  CSEs  have  played  a  role,  a  much  higher 
percentage  of  CSEs  have  played  the  role  than  seen  in  the  general  Helix  sample.  For 
example,  79%  of  CSEs  have  played  the  role  of  Requirements  Owner  while  in  the  overall 
Helix  sample,  this  number  is  just  over  47%. 

It  is  clear  that  the  percentage  of  CSEs  who  have  played  these  roles  continues  to  rise  even  after 
their  first  CSE  position  and  overall,  the  percentage  of  CSEs  who  have  played  these  roles  is 
considerably  higher  than  in  the  general  Helix  population.  This  indicates  that  CSEs  overall  have 
experiences  playing  a  wider  range  of  roles  and  that  this  broad  variety  of  roles  continues 
throughout  their  careers;  it  does  not  stop  when  they  earn  the  title  of  "Chief  Systems  Engineer". 


4.2.  Insights  from  INCOSE  ESEP  Analysis 

Among  the  three  levels  of  INCOSE  SEP  certification,  ESEP  is  the  highest  category.  ESEP 
applicants  are  required  to  submit  information  of  twenty  or  more  years  of  work  history  relevant 
to  systems  engineering,  and  are  therefore  expected  to  possess  significant  experience  in  systems 
engineering.  In  the  seniority  levels  defined  by  Helix,  ESEPs  that  are  successfully  certified  are 
Senior  systems  engineers. 

As  discussed  above,  analyzing  the  career  paths  of  CSEs  provides  some  insights  for  career 
development.  Similarly,  within  the  INCOSE  SEP  data  from  certified  ESEP  applicants,  a  subset  of 
those  who  have  held  a  CSE  position  or  a  position  equivalent  to  CSE  was  analyzed.  A  category 
called  'ChiefX'  was  identified,  that  included  certified  ESEPs  who  have  held  CSE  titles  or  other 
equivalent  titles,  specifically.  Chief  Engineer,  Chief  Architect,  Chief  Systems  Architect,  Chief 
Principal  Engineer,  and  Chief  of  Systems  Engineering.  A  comparison  of  CSEs  from  the  Helix 
interview  data  and  ChiefXs  from  INCOSE  SEP  data  was  used  to  partially  validate  the  Helix 
sample  against  a  larger  diverse  international  sample  of  systems  engineers. 


4.2.1. Education  of  ChiefXs 

Table  9  compares  the  highest  degrees  obtained  by  CSEs  in  the  Helix  interview  data  and  ChiefXs 
from  the  INCOSE  SEP  data.  The  highest  degrees  compare  well  between  the  two  samples.  The 
CSEs  in  the  Helix  sample  have  a  slightly  higher  rate  of  master's  degree  attainment,  while  the 
ChiefXs  a  slightly  higher  rate  in  PhDs. 
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Table  9.  Highest  Degree  Attained  for  CSEs  (Helix  interviewees)  and  ChiefXs  (ESEPs) 


Degree  Level 

CSEs 

ChiefXs 

Associate's 

0% 

0% 

Bachelor's 

20% 

23% 

Master's 

64% 

60% 

Doctorate 

16% 

17% 

Figure  35  compares  the  bachelor's  degree  majors  of  CSEs  and  ChiefXs.  Electrical  engineering 
comes  out  as  the  most  popular  major  in  both  samples.  Though  there  are  some  variations, 
mechanical  engineering,  computer  engineering  /  science  are  the  next  popular  majors  for 
ChiefXs.  There  are  some  majors  such  as  civil  engineering,  aerospace  or  aeronautical 
engineering,  and  industrial  engineering  that  are  found  in  one  sample  but  not  in  the  other. 


Figure  35.  Comparison  of  Bachelor's  Degree  Majors  between  CSEs  and  ChiefXs 

Figure  36  compares  the  master's  degree  majors  of  CSEs  and  ChiefXs.  The  most  prevalent 
master's  degree  major  attained  was  in  the  area  of  business  -  38%  of  the  CSEs  and  39%  of  the 
ChiefXs  sought  a  management  master's.  Most  frequently  this  was  an  MBA  or  other 
management  variant.  A  little  less  than  a  quarter  of  CSEs  and  ChiefXs  pursued  a  master's  in 
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electrical  engineering.  Almost  10%  of  CSEs  and  13%  of  ChiefXs  complete  a  master's  in  systems 
engineering.  The  trends  observed  in  master's  degree  majors  indicate  similar  education  profiles 
for  both  the  CSEs  and  the  ChiefXs. 
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Figure  36.  Comparison  of  Master's  Degree  Majors  between  CSEs  and  ChiefXs 

As  shown  in  Table  9,  17%  of  the  ChiefXs  have  doctorate  degrees.  This  is  much  greater  than  in 
the  Helix  sample,  of  which  9%  of  CSEs  have  doctorate  degrees.  Similar  to  findings  from  the  Helix 
sample,  there  was  minimal  convergence  in  any  specific  academic  discipline  for  doctoral  study. 
Of  the  ChiefXs,  13%  of  the  applicants  sought  a  doctor  of  philosophy  in  engineering,  mechanical 
engineering,  computer  science  and  systems  engineering/integration;  the  other  4%  includes 
doctorate  degrees  such  as  Applied  Mechanics  and  Juris  Doctor. 


4.2.2.  Career  Roles  Played  by  Certified  ESEP's  and  ChiefXs 

Helix  identified  the  Atlas  roles  among  INCOSE  ESEP  applicants,  using  text-based  searches. 
Figure  37  compares  the  roles  played  by  senior  systems  engineers  and  CSEs  from  the  Helix 
interview  data,  compares  the  roles  played  by  certified  ESEPs  (non  ChiefXs)  and  ChiefXs  from  the 
INCOSE  SEP  data.  In  Figure  38,  they  are  provided  along  with  the  roles  for  senior  systems 
engineers  in  Helix  and  ESEPs  for  the  INCOSE  dataset.  This  provides  a  point  of  comparison  -  i.e. 
are  there  clear  differences  in  the  roles  that  senior  systems  engineers  who  have  become  CSEs 
played  compared  to  those  of  who  have  not  yet  reached  that  level? 
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Comparison  of  Career  Roles  of  Helix  and  INCOSE  ESEP's  and  ChiefX's 
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Figure  37.  Comparison  of  Roles  Played  Throughout  Career  between  Helix  Interview  Data  and  INCOSE  SEP  Data 


The  career  roles  played  by  the  INCOSE  certified  ESEPs  and  ChiefXs  most  closely  resemble  the 
roles  played  by  the  CSEs  in  the  Helix  sample.  Since  INCOSE  has  an  extremely  selective  process 
for  certifying  ESEPs,  the  individuals  that  receive  the  certification  have  Experiences  equivalent  to 
the  CSEs  in  the  Helix  sample  rather  than  the  senior  systems  engineers.  Therefore,  the  senior 
systems  engineers,  while  they  are  more  seasoned  than  junior  or  mid-level  systems  engineers, 
do  not,  in  general,  have  the  breadth  and  depth  of  Experiences  in  different  roles  as  compared  to 
the  CSEs,  the  ESEPs  (non-ChiefXs),  and  the  ChiefXs. 

Additional  insights  include: 

•  The  Organizational/Functional  Manager  role  is  more  common  in  the  Helix  interview 
sample.  This  could  imply  that  either  those  who  apply  for  ESEP  are  more  likely  to  be  in  a 
technical  track  and  therefore  not  have  the  experience  in  management  to  take  on  this 
type  of  role;  or  ESEP  applicants  omitted  reporting  such  roles  since  the  application  form 
solicited  only  systems  engineering  related  tasks  and  functions. 

•  The  Helix  sample  identified  the  most  seasoned  systems  engineers  who  hold  critical 
systems  positions  are  only  occasionally  instructors  at  some  point  in  their  career.  But  in 
the  ESEP  applications,  the  role  of  instructor  is  called  out  more  explicitly,  and  applicants 
are  requested  to  provide  details  on  training.  This  may  have  led  to  a  higher  reporting  rate 
among  ESEPs  than  CSEs  among  Helix  interviewees  for  the  role  Instructor. 
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•  The  Helix  sample  showed  that  systems  engineers  often  play  multiple  roles  while  they 
are  in  a  single  position.  This  finding  was  mirrored  in  the  ChiefX  subset.  More  than  half  of 
the  ChiefXs  had  compound  titles,  and  therefore  it  was  assumed  they  were  actively 
performing  multiple  roles.  The  most  frequent  keywords  in  ChiefX  compound  titles 
indicate  that  organizational  leadership  is  typically  a  complementary  position  to  CSE. 
Three  of  the  most  frequent  keywords  in  ChiefX  compound  titles  were  Manager  (17%), 
Lead  (12%),  and  Director/Head  (11%).  The  other  frequent  keyword.  Architect  (8%) 
indicates  that  CSEs  hold  technical  and  system-specific  roles. 

•  For  all  ChiefXs  who  held  3  or  more  ChiefX  titles  at  some  point  in  their  careers  (15%  of 
the  ChiefX  subset),  each  individual  progressed  into  larger  and  more  complex  systems. 
The  Helix  sample  showed  that  one  common  career  path  for  systems  engineers'  stems 
from  a  highly  technical  position,  and  through  the  growth  of  their  careers,  the  systems 
engineers  take  on  more  responsibility  and  leadership  roles,  which  correlates  with 
growing  of  interpersonal  skills. 


4.2.3.  Roles  Played  in  First  ChiefX  Position 

Figure  38  provides  a  comparison  of  the  roles  played  by  ChiefXs  in  their  first  ChiefX  position  and 
roles  played  by  CSEs  in  their  first  CSE  position  from  the  Helix  interviewee  dataset. 


Roles  Played  at  the  First  ChiefX  and  CSE  Positions 


Roles 

S3  Helix  Dataset  ■  ChiefX 


Figure  38.  Roles  Played  in  First  ChiefX  and  CSE  Positions 
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As  is  seen  in  Figure  38, 


•  The  roles  played  most  commonly  during  the  first  ChiefX  position  are  Requirements 
Owner,  Technical  Manager,  Validation  and  Verification  Engineer,  System  Designer,  and 
System  Analyst. 

•  The  CSE  sample  experienced  technical  and  programmatic  management  aspects  of 
systems  rather  than  the  more  technical  system  lifecycle  roles  that  were  experienced  by 
the  ChiefXs. 

•  Almost  half  (45%)  of  the  ChiefXs  played  ten  or  more  different  roles  in  their  first  ChiefX 
position  -  35%  played  between  5  and  9  roles  (inclusive),  and  20%  played  less  than  5 
roles.  Only  the  Program  Manager  and  Organizational/Functional  Manager  roles  are 
performed  by  less  than  40%  of  the  ChiefXs. 

•  Almost  half  of  the  ChiefXs  played  the  role  of  Instructor/Teacher  while  in  their  first  ChiefX 
position.  This  indicates  the  knowledge  base  of  these  individuals,  and  their  willingness  to 
share  their  critical  understanding  and  experiences  with  others,  ultimately  leading  to  an 
improvement  of  their  organization.  This  aligns  nicely  with  the  Helix  data,  wherein  over 
half  of  CSEs  played  this  role  during  their  first  CSE  position. 


4.2.4.  Value  of  INCOSE  SEP  Analysis  for  Atlas 

The  INCOSE  data  was  an  excellent  benchmark  for  the  Helix  sample.  Characteristics  and  patterns 
identified  in  Atlas  were  further  evidenced  via  comparison  of  certified  ESEPs  and  ChiefXs  with 
the  senior  systems  engineers  and  CSEs  from  the  Helix  interview  sample.  There  were  no  major 
discrepancies  that  would  indicate  a  need  for  reassessment  of  Atlas.  INCOSE  SEP  applications 
provided  a  wealth  of  data  for  use  in  identifying  the  Education  and  Experience  backgrounds  of 
those  who  have  been  systems  engineers  in  industry  for  over  20  years,  and  are  certified  as 
knowledgeable,  experienced  and  accomplished  professionals  in  systems  engineering. 
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5.  Bringing  Things  Full  Circle:  Relating  Career  Paths  to  Proficiency 


This  section  provides  highlights  on  the  linkages  between  a  systems  engineer's  career  path  and 
proficiency.  It  utilizes  self-assessments  of  proficiency  and  compares  them  with  the  Helix  team's 
analysis  of  individuals  with  similar  self-assessments.  Sections  5.1  and  5.2  also  highlight  the 
Captsone  project  by  Mr.  Matthew  Partacz. 


5.1.  Capstone  Project  Results:  Linking  Career  Paths  with  Proficiency 

The  following  highlights  results  of  a  capstone  project  conducted  in  conjunction 
with  Helix.  Additional  details  on  the  results  highlighted  in  Section  5  may  be  found 
in  Building  a  Better  Business  Case  for  Systems  Engineering:  The  Relationship 
between  a  Systems  Engineer's  Career  Path,  Proficiency  and  Project  Performance 
written  by  Matthew  Partacz  (2017).  Note  that  for  this  analysis,  the  proficiency 
assessments  are  reported  on  a  scale  of  1-10  rather  that  the  1-5  scale  used  in 
Atlas  1.1.  This  translates  to  the  Atlas  scale  by  dividing  by  2.  (E.G.  an  "8"  below 
is  the  same  as  a  "4"  in  AtlasJ. 

In  order  to  prove  the  relationship  between  an  individual's  career  path  and  their  proficiency  of 
Systems  Engineering  (SE),  the  following  hypothesis  was  assessed: 

Career  path  has  a  guantifiable  impact  on  an  individual's  systems  engineering  (SE)  proficiency. 

The  analysis  of  the  collected  data  shows  that  there  are  identifiable  and  significant  relationships 
between  career  path  and  systems  engineering  proficiency.  Figure  39  shows  that  for  a  new 
engineer,  only  17%  have  higher  systems  engineering  proficiency  and  58%  have  lower  systems 
engineering  proficiency,  while  for  an  experienced  engineer  who  has  been  titled  a  systems 
engineer,  38%  have  higher  systems  engineering  proficiency  and  27%  have  lower  systems 
engineering  proficiency.  The  explored  relationship  has  a  confidence  of  94.7%.  Overall,  there  is 
a  very  strong  positive  relationship  between  combined  SE  proficiency  and  experience. 
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Figure  39.  Experience  vs.  Current  Combined  SE  Proficiency 

In  addition  to  looking  at  the  combined  systems  engineering  proficiency,  each  of  the  six  areas  of 
systems  engineering  proficiency  were  compared  to  career  path  and  are  summarized  in  Table 
10. 


Table  10.  Summary  of  SE  Proficiency  vs  Experience,  non-parametric  statistical  analysis 


SE  Proficiency 

Gamma 

p-value 

Math/  Science/  General  Engineering 

-0.32 

0.880 

Systems'  Domain  &  Operational  Context 

0.51 

0.025 

Systems  Engineering  Discipline 

0.53 

0.015 

Systems  Engineering  Mindset 

0.53 

0.022 

Interpersonal  Skills 

-0.01 

0.507 

Technical  Leadership 

0.50 

0.023 

Combined  SE 

0.42 

0.053 

Exploring  the  results  shown  in  Table  10  Math/  Science/  General  Engineering  Proficiency  was 
found  to  have  a  Gamma  of  strong  negative  relationship  to  experience  with  a  confidence  of 
12.0%.  This  result  is  due  to  the  limitations  of  non-parametric  statistical  analysis,  in  which  the 
order  of  new  engineer,  experience  and  never  titled  systems  engineer,  and  experienced  and 
titled  systems  engineer  is  assumed  to  be  in  increasing  order.  However,  it  was  determined  that 
from  all  HELIX  interviews  conducted  that  an  experienced  and  titled  systems  engineer  would 
have  the  lowest  math/  science/  general  engineering  proficiency,  and  an  experienced  and  never 
titled  systems  engineer  would  have  the  highest  math/  science/  general  engineering  proficiency. 


Report  No.  SERC-2018-TR-101-C 


66 


January  16,  2018 


This  fact  voids  this  particular  non-parametric  statistical  analysis.  Further  exploring  the  results 
shown  in  table  x.  Interpersonal  Skills  was  found  to  have  a  weak  to  non-existent  relationship  to 
experience  with  a  confidence  of  49.3%.  This  relationship  suggests  interpersonal  skills  are  not 
improved  from  experience,  however  an  increased  sample  size  would  be  required  to  confirm  the 
relationship  seen  from  the  HELIX  sample.  All  other  SE  proficiencies  shown  in  table  x  were  found 
to  have  very  strong  positive  relationships  to  experience  with  the  confidence  no  lower  than 
97.5%. 


5.2.  Capstone  Results:  Proficient  Systems  Engineers  Improve  Project  Performance 

Helix  partnered  with  a  master's  student  to  explore  the  relationship  between  SE  proficiency  and 
project  performance  within  the  Helix  dataset. 

In  order  to  prove  the  relationship  between  an  individual's  proficiency  of  Systems  Engineering 
(SE)  and  their  project  performance,  the  following  hypothesis  was  assessed: 

An  individual's  systems  engineering  proficiency  yields  guantifiable  improvements  in  program 
execution  (e.g.,  improved  cost  performance,  schedule  performance,  and  technical  performance). 

•  Examination  of  the  collected  data  comparing  individual's  systems  engineering 
proficiency  and  program  execution  was  determined  to  be  inconclusive.  This  portion  of 
the  study  had  a  limited  sample  size  of  28,  and  cannot  be  used  identify  any  patterns  or  to 
generalize  an  entire  population.  Moreover  the  relationships  seen,  at  best,  have  a  57.5% 
confidence.  With  a  greater  overall  sample  size,  response  distributions  should  normalize 
and  better  relationships  can  be  observed  with  a  greater  confidence. 

•  Findings  for  the  relationship  between  systems  engineering  proficiency  and  overall 
program  execution  are  summarized  in  Table  11. 

Table  11.  Summary  of  SE  Proficiency  vs.  Overall  Project  Performance,  Non-parametric  statistical  analysis 


SE  Proficiency 

Gamma 

p-  value 

Math/  Science/  General  Engineering 

0.00 

0.500 

Systems'  Domain  &  Operational  Context 

-0.12 

0.614 

Systems  Engineering  Discipline 

-0.11 

0.608 

Systems  Engineering  Mindset 

-0.03 

0.530 

Interpersonal  Skills 

0.04 

0.465 

Technical  Leadership 

0.08 

0.425 

Combined  SE 

-0.20 

0.685 

Insights  resulting  from  this  limited  study  could  help  organizations  make  a  business  case  for 
investments  in  systems  engineers.  Organizations  could  also  better  identify  candidates  for 


Report  No.  SERC-2018-TR-101-C 


67 


January  16,  2018 


systems  engineering  positions  and  create  workforce  development  programs  to  improve  their 
overall  systems  engineering  capability. 


5.1.  Linking  Proficiency  to  Career  Paths  in  the  Helix  Dataset 

Using  the  approach  developed  by  Partacz  (2017),  the  Helix  team  linked  the  career  path  dataset 
with  individuals  who  had  completed  self-assessments  of  their  proficiencies.  While  the  team 
notes  that  self-assessments  can  be  biased,  they  nevertheless  are  useful  in  understanding  the 
patterns  between  what  an  individual  has  done  and  what  she  believes  she  has  learned. 


5. 1.1. Overview  of  Atlas  Proficiency  Model 

Proficiency  is  defined  in  Atlas  as  "knowledge,  skills,  abilities,  behaviors,  and  cognitions" 
(KSABCs).  Specifically,  these  are  the  KSABCs  identified  throughout  the  Helix  dataset  as  critical 
for  systems  engineers  to  be  effective.  The  Atlas  proficiency  model  consists  of  six  proficiency 
areas  -  groupings  of  related  KSABCs  -  based  on  the  Helix  interview  data,  as  shown  in 

Figure  40  below.  An  overview  of  the  model  is  provided  here  and  additional  detail  is  provided  in 
context  with  the  results  for  proficiency  assessments  for  each  area.  For  the  full  Atlas  proficiency 
model,  please  see  Atlas  1.1. 


Math  /  Science  / 
General  Engineering 


Systems  Engineering 
Mindset 


Figure  40.  Proficiency  Areas  for  Systems  Engineers 


1.  Math/Science/General  Engineering:  Foundational  concepts  from  mathematics, 
physical  sciences,  and  general  engineering; 

2.  System's  Domain  &  Operational  Context:  Relevant  domains,  disciplines,  and 
technologies  for  a  given  system  and  its  operation; 

3.  Systems  Engineering  Discipline:  Foundation  of  systems  science  and  systems 
engineering  knowledge; 

4.  Systems  Engineering  Mindset:  Skills,  behaviors,  and  cognition  associated  with  being  a 
systems  engineer; 
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5.  Interpersonal  Skills:  Skills  and  behaviors  associated  with  the  ability  to  work  effectively 
in  a  team  environment  and  to  coordinate  across  the  problem  domain  and  solution 
domain;  and 

6.  Technical  Leadership:  Skills  and  behaviors  associated  with  the  ability  to  guide  a  diverse 
team  of  experts  toward  a  specific  technical  goal. 

Proficiency  areas  1  to  3  consist  of  primarily  'hard'  or  technically  based  skills,  while  proficiency 
areas  4  to  6  consist  primarily  of  the  'soft'  or  interdisciplinary  skills.  Development  and  evaluation 
of  soft  skills  is  addressed  by  the  disciplines  of  psychology,  social  sciences,  and  management 
sciences.  The  six  proficiency  areas  in  Atlas  are  further  divided  into  categories  and,  in  some 
cases,  into  topics,  as  shown  in  Table  12.  Each  of  the  proficiency  areas  is  elaborated  in  the 
subsequent  sections. 


Table  12.  Atlas  Proficiency  Areas,  Categories,  and  Topics 


Area 

Category 

Topic 

1.  Math  /  Science  /  General  Engineering 

1.1.  Natural  Science 

Foundations 

1.2.  Engineering  Fundamentals 

1.3.  Probability  and  Statistics 

1.4.  Calculus  and  Analytical 
Geometry 

1.5.  Computing  Fundamentals 

2.  Systems'  Domain  &  Operational  Context 

2.1.  Principal  and  Relevant 
Systems 

<  List  of  Principal  and 

Relevant  Systems  > 

2.2.  Familiarity  with  Principal 
System's  Concept  of 
Operations  (ConOps) 

2.3.  Relevant  Domains 

<  List  of  relevant  Domains  > 

2.4.  Relevant  Technologies 

<  List  of  relevant 

Technologies  > 

2.5.  Relevant  Disciplines  and 
Specialties 

<  List  of  relevant  Disciplines 
and  Specialties  > 

2.6.  System  Characteristics 

<  List  of  applicable  System 
Types,  Scales,  and  Levels  > 

3.  Systems  Engineering  Discipline 

3.1.  Lifecycle 

3.1.1  Lifecycle  Models 

3.1.2  Concept  Definition 

3.1.3  System  Definition 

3.1.4  System  Realization 

3.1.5  System  Deployment 
and  Use 

3.1.6  Product  and  Service 

Life  Management 

3.2.  Systems  Engineering 
Management 

3.2.1  Planning 

3.2.2  Risk  Management 

3.2.3  Configuration 
Management 

3.2.4  Assessment  and 

Control 

3.2.5  Quality  Management 
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Area 

Category 

Topic 

3.3.  SE  Methods,  Processes,  and 
Tools 

3.3.1  Balance  and 

Optimization 

3.3.2  Modeling  and 

Simulation 

3.3.3  Development  Process 

3.3.4  Systems  Engineering 
Tools 

3.4.  Systems  Engineering  Trends 

3.4.1  Complexity 

3.4.2  Model  Oriented 

Systems  Engineering 

3.4.3  Systems  Engineering 
Analytics 

3.4.4  Agile  Systems 

Engineering 

4.  Systems  Engineering  Mindset 

4.1.  Big-Picture  Thinking 

4.2.  Paradoxical  Mindset 

4.2.1  Big-Picture  Thinking 
and  Attention  to  Detail 

4.2.2  Strategic  and  Tactical 

4.2.3  Analytic  and  Synthetic 

4.2.4  Courageous  and 

Flumble 

4.2.5  Methodical  and 

Creative 

4.3.  Flexible  Comfort  Zone 

4.4.  Abstraction 

4.5.  Foresight  and  Vision 

5.  Interpersonal  Skills 

5.1.  Communication 

5.1.1  Audience 

5.1.2  Content 

5.1.3  Mode 

5.2.  Listening  and 

Comprehension 

5.3.  Working  in  a  Team 

5.4.  Influence,  Persuasion  and 
Negotiation 

5.5.  Building  a  Social  Network 

6.  Technical  Leadership 

6.1.  Building  and  Orchestrating 
a  Diverse  Team 

6.2.  Balanced  Decision  Making 
&  Rational  Risk  Taking 

6.3.  Guiding  Stakeholders  with 
Diverse/Conflicting  Needs 

6.4.  Conflict  Resolution  & 

Barrier  Breaking 

6.5.  Business  and  Project 
Management  Skills 

6.6.  Establishing  Technical 
Strategies 

6.7.  Enabling  Broad  Portfolio- 
Level  Outcomes 
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Throughout  the  remainder  of  this  section,  individuals  with  the  highest  proficiency  self- 
assessments  are  individuals  who  reported  attaining  a  "7  or  higher"  on  a  10-point  scale  for 
their  self-assessments.  With  the  updated  Atlas  rubric,  these  would  equate  to  individuals 
who  rated  themselves,  "4/Advanced"  or  "5/Expert"). 


5.1.2.  Math/Science/General  Engineering 

A  good  understanding  of  math,  science,  and  general  engineering  is  a  critical  foundation  for 
effective  systems  engineers;  but  this  understanding  is  largely  'assumed'  in  a  systems  engineer 
when  joining  the  workforce  since  proficiency  in  this  area  is  not  utilized  directly  or  in  isolation. 
However,  it  is  upon  this  foundation  that  further  understanding  of  the  categories  under 
Proficiency  Area  2:  Systems'  Domain  &  Operational  Context  is  built. 

The  Graduate  Reference  Curriculum  for  Systems  Engineering  (GRCSE®)  defines  the  types  of 
prerequisite  knowledge  individuals  should  have  before  entering  a  master's  program  in  systems 
engineering  (Pyster  et  al.  2015).  Since  limited  insight  was  obtained  from  Helix  data  collection 
and  analysis  for  this  proficiency  area,  GRCSE  is  used  to  identify  and  define  the  categories  in  this 
area: 

1.1.  Natural  Science  Foundations:  Basic  concepts  and  principles  of  one  of  the  natural 
science  disciplines  (e.g.,  physics,  biology,  chemistry,  etc.);  includes  laboratory  work  that 
involves  experimental  techniques,  the  application  of  the  scientific  method,  and 
comprehension  of  appropriate  methods  for  data  quality  assurance  and  analysis. 

1.2.  Engineering  Fundamentals:  The  nature  of  engineering,  branches  of  engineering,  the 
design  process,  analysis  and  modeling,  the  role  of  empirical  and  statistical  techniques, 
problem  solving  strategies,  and  the  value  of  standards;  some  level  of  practical 
experience  is  expected,  whether  through  capstones,  internships,  or  course  projects. 
Practical  experience  should  include  the  application  of  engineering  fundamentals  in  a 
specific  domain  context. 

1.3.  Probability  and  Statistics:  Basic  probability  theory,  random  variables  and  probability 
distributions,  estimation  theory,  hypothesis  testing,  regression  analysis,  and  analysis  of 
variance. 

1.4.  Calculus  and  Analytical  Geometry:  Theory  and  application  of  differential  and  integral 
calculus  methods  and  operations;  study  of  techniques  for  describing,  representing,  and 
analyzing  geometric  objects  (coordinate  systems,  algebraic  models,  graphing). 

1.5.  Computing  Fundamentals:  Overview  of  computer  organization  (computer  architecture, 
operating  systems,  and  programming  languages),  algorithms,  and  data  structures; 
software  engineering  fundamentals  (lifecycle  models,  quality,  cost,  and  schedule  issues); 
and  development  of  a  software  unit  (design,  coding,  and  testing). 

Proficiencies  in  Area  1:  Math/Science/General  Engineering  may  be  considered  as  the  general 
foundation  that  is  provided  in  any  undergraduate  engineering  degree.  Advanced  levels  of  these 
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topics  are  included  in  the  topics  of  Area  2,  in  the  context  of  the  system  of  concern.  For  an 
individual  without  a  formal  undergraduate  degree  in  engineering,  obtaining  the  proficiencies  in 
Area  1  could  happen  through  experience,  training,  or  mentoring. 

As  it  can  be  observed  in  Figure  42,  more  than  half  of  systems  engineers  identified  their 
Math/Science/General  Engineering  skills  to  be  "between  7  and  8".  Again,  this  is  on  the  previous 
10-point  scale;  this  translates  to  "4/Advanced"  to  "5/Expert"  in  the  updated  rubric.  None  of  the 
participants  graded  themselves  with  a  grade  of  1  or  2  (which  equates  to  "1/Novice"  in  the  new 
rubric). 

Current  Math/  Science/  General  Engineering  Proficiency 
Response  Distribution 

60% 

50% 

40% 

30% 

20% 

■  ■  ■  ■ 

0% 

1  or  2  3  or  4  5  or  6  7  or  8  9  or  10 

Proficiency  Distribution 

Figure  41.  Proficiency  Distribution  for  Math/Science/General  Engineering 

Next,  the  team  uses  information  of  the  most  popular  responses  (7  or  8)  to  provide  an  example 
of  what  proficiency  patterns  might  be  discovered.  Information  from  individuals  who  self-graded 
with  a  7  or  an  8  was  retrieved  to  examine  for  patterns  in  terms  of,  systems  type,  organization 
type  and  roles. 

Figure  42  illustrates  that  all  systems  engineers  who  responded  7  or  8  to  the 
Math/Science/General  Engineering  proficiency  model  have  been  exposed  to  the  component 
level.  Also,  more  than  three-quarters  of  those  participants  are  exposed  to  the  subsystem  and 
system.  Only  14%  of  those  interviewed  have  been  exposed  to  the  Platform/Systems  of  System 
type  of  system. 
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Figure  42.  Distribution  for  individuals  with  highest  proficiency  self-assessment  in  Math/Science/General 

Engineering 

In  regard  to  the  type  of  organization,  91%  of  engineers  who  responded  7  or  8  to  Math/Science/ 
General  Engineering  have  experience  in  the  industry.  Less  than  half  of  participants  (45%)  have 
been  involved  in  government-type  of  organizations  while  no-systems  engineer  have  Academic 
experience.  Figure  43  illustrates  the  organization  type  for  those  participants  who  answer  7  or  8. 


100% 

80% 

<u 

M 

2  60% 
£  40% 

dj 

CL 

20% 

0% 


Organization  Types  for  Individuals  with  Highest 
Proficiency  Self-Assessments 


Government  Industry 


Academia 


Organization  Type 

Figure  43.  Distribution  for  organization  types  for  individuals  with  the  highest  proficiency  self-assessments  in 

Math/Science/General  Engineering 

Figure  44  denotes  the  most  frequent  roles  for  individuals  who  graded  themselves  7  or  8.  As  it 
can  be  observed,  all  participants  played  the  role  of  coordinator.  Verification  and  Validation  is 
the  second  most  frequent  role  while  Instructor  or  Teacher  is  the  least  common  role. 
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Roles  Played  by  Individuals  with  Highest  Proficiency  Self-Assessment 
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Figure  44.  Roles  distribution  for  individuals  with  highest  proficiency  self-assessments  in  Math/Science/General 

Engineering 


5.1.3.  System's  Domain  &  Operational  Context 

The  second  proficiency  area  is  System's  Domain  &  Operational  Context,  which  contains  the 
relevant  domains,  technologies,  disciplines,  specialties,  and  characteristics  for  a  given  system, 
and  the  operation  of  that  system.  This  proficiency  area  strongly  corresponds  to  the  organization 
and  the  systems  that  its  systems  engineers  work  on.  If  an  individual  transitions  to  a  new  system 
either,  the  proficiency  level  may  change  depending  on  familiarity  with  the  new  relevant 
domains,  technologies,  and  disciplines.  The  categories  for  this  proficiency  area  are  defined 
below: 

2.1.  Principal  and  Relevant  Systems:  Principal  systems  are  those  systems  that  are  of  primary 
interest  to  the  organization.  High  levels  of  proficiency  in  those  specific  systems  are 
desired  by  the  organization.  If  a  combat  ship  were  the  principal  system,  relevant 
systems  could  be  submarines  and  aircraft  carriers,  which  are  types  of  combat  ships. 

2. 2.  Familiarity  with  Principal  System's  Concept  of  Operations  (ConOps):  A  system's 
concept  of  operations  (ConOps)  of  how  systems  in  the  domain  are  used  and  deliver 
value,  especially  those  systems  on  which  the  individual  personally  works.  Familiarity 
with  the  principal  system's  ConOps  is  of  particular  interest,  though  familiarity  with  the 
ConOps  of  other  related  systems  may  also  be  helpful. 

2. 3.  Relevant  Domains:  Domain  refers  to  the  overarching  area  of  application  of  the  system; 
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this  includes  things  such  as  space,  aerospace,  marine,  communication,  finance,  etc. 
Proficiency  in  related  domains  outside  the  primary  one  may  enable  an  individual  to  be 
more  effective  in  the  primary  domain.  For  example,  experience  in  space  systems  may 
enable  a  systems  engineer  to  work  in  aerospace  systems  more  readily  than  an  engineer 
who  is  proficient  primarily  in  finance  systems. 

2.4.  Relevant  Technologies:  Within  the  context  of  a  system,  there  are  specific  technologies 
that  are  relevant.  For  example,  on  a  marine  system,  these  may  be  technologies  such  as 
gas  turbine,  radar,  and  sonar  systems;  and  each  technology  has  its  own  terminology, 
challenges,  etc. 

2. 5.  Relevant  Disciplines  and  Specialties:  Disciplines  are  fundamental  areas  of  education  or 
expertise  that  are  foundational  to  a  system.  For  example,  for  a  communications  system, 
electrical  engineering  will  be  an  important  discipline  to  understand,  while  civil 
engineering  will  be  less  relevant.  Specialties  are  disciplines  that  support  systems 
engineering  by  applying  cross-cutting  knowledge.  Specialties  include  Reliability, 
Availability,  and  Maintainability  (RAM),  Fluman  Systems  Integration,  Safety  Engineering, 
Affordability  and  other  related  topics. 

2. 6. System  Characteristics:  Three  characteristics  are  considered  in  Atlas : 

o  System  Type:  Types  of  systems  include  technical  systems,  social  systems,  human 
systems,  physical  systems,  cyber  systems,  and  any  combination  of  these. 
Another  classification  of  system  types  includes  product  systems,  service  systems, 
and  enterprise  systems. 

o  System  Scale  Systems  can  be  anywhere  from  a  nano  level  to  a  distributed  global 
or  enterprise  level.  A  generic  systems  engineering  development  process  may  be 
applicable  to  systems  at  any  scale. 

o  System  Scope:  What  can  be  seen  as  a  system  from  one  perspective,  could  be  a 
subsystem  from  another  perspective.  The  levels  of  a  system  could  range  from 
component/element,  subsystem,  system,  and  platform  or  system  of  systems. 

Category  2.6  is  a  change  from  older  versions  of  Atlas.  In  previous  versions,  there  was  a  category 
called  "System  Complexity"  under  Proficiency  Area  3  (Systems  Engineering  Discipline). 
Flowever,  as  the  Helix  team  worked  with  organizations  that  were  implementing,  questions 
arose  about  other  systems  aspects  in  the  proficiency  model.  For  example,  there  was  a  concern 
that  system  complexity  was  identified  but  not  the  scope  of  a  system  nor  different  system 
scopes  from  element  to  system  of  systems.  The  Helix  team  agreed  that  though  these  were 
covered  in  the  experiences  of  systems  engineers,  this  was  a  gap  in  the  existing  proficiency 
model.  After  reviewing  discussions  on  proficiency  from  the  data,  the  team  determined  that 
several  characteristics  should  be  called  out.  Because  these  were  related  to  the  types  of 
systems,  the  team  determined  that  the  new  category,  "System  Characteristics",  was  a  better  fit 
in  Proficiency  Area  2  (System's  Domain  and  Operational  Context). 

Note  that  this  refers  to  the  ability  of  an  individual  to  work  effectively  on  systems  with  different 
characteristics.  This  is  related  to,  but  distinct  from,  experiences  an  individual  has  on  these  types 
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of  systems. 


As  it  can  be  observed  in  Figure  45,  more  than  half  of  systems  engineers  identified  their  Domain 
&  Operational  Context  skills  to  be  between  7  and  8.  None  of  the  participants  graded  themselves 
with  a  grade  of  1  or  2  or  the  grades  3  or  4. 
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Figure  45.  Proficiency  distribution  for  System's  Domain  and  Operational  Proficiency  responses 

Figure  46  illustrates  that  more  than  three-quarters  of  systems  engineers  who  responded  7  or  8 
to  the  Domain  and  Operational  Context  proficiency  model  have  been  exposed  to  the 
component,  subsystem  and  system  level.  Also,  only  10%  of  those  interviewed  have  been 
exposed  to  the  Platform/Systems  of  System  type  of  system. 
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Figure  46.  Distribution  for  system  types  of  individuals  with  the  highest  proficiency  self-assessments  in  System's 

Domain  and  Operational  Context 
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In  regard  to  the  type  of  organization,  92%  of  engineers  who  responded  7  or  8  to  System's 
Domain  and  Operational  Context  have  experience  in  the  industry.  One  in  three  participants 
(33%)  have  been  involved  in  government  while  only  8%  have  Academic  experience.  Figure  47 
illustrates  the  organization  type  for  those  participants  who  answer  7  or  8. 
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Figure  47.  Distribution  for  organization  types  for  individuals  with  the  highest  proficiency  self-assessments  in 

System's  Domain  and  Operational  Context 


<u 

oo 

ro 


aj 

a. 


Figure  48  denotes  the  most  frequent  roles  for  individuals  who  graded  themselves  7  or  8.  As  it 
can  be  observed,  most  participants  played  the  role  of  Coordinator.  Verification  and  Validation 
(79%)  as  well  as  Detailed  Designer  (79%)  are  the  second  most  frequent  roles.  The  least  played 
role  is  Instructor  or  Teacher  with  only  (7%). 
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Roles  Played  by  Individuals  with  Highest  Proficiency  Self-Assessments 
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Figure  48.  Roles  distribution  for  individuals  with  the  highest  proficiency  self-assessments  in  System's  Domain 

and  Operational  Context 


5.1.4.  Systems  Engineering  Discipline 

The  third  proficiency  area  is  Systems  Engineering  Discipline.  The  categories  below  were 
developed  based  on  data  from  Helix  interviews  about  critical  systems  engineering  knowledge 
and  skills.  The  names  of  the  categories  come  from  the  Guide  to  the  Systems  Engineering  Body  of 
Knowledge  (SEBoK)  (BKCASE  Editorial  Board  2016).  Some  of  the  categories  are  further 
expanded  into  topics. 

3.1. Lifecycle:  The  organized  collection  of  activities,  relationships  and  contracts  that  apply  to 
a  system-of-interest  during  its  life  (Pyster  2009).  This  is  a  roll  up  of  knowledge  about 
lifecycles  and  proficiency  in  specific  aspects  of  the  lifecycle.  Topics  3.1.2  -  3.1.6  below, 
represent  generic  lifecycle  phases  in  system  development: 

3.1.1.  Lifecycle  Models  A  framework  of  processes  and  activities  concerned  with  the 
lifecycle  that  may  be  organized  into  stages,  which  also  acts  as  a  common 
reference  for  communication  and  understanding  (ISO/I EC/I EEE  15288).  Lifecycle 
Models  include  Vee  model;  iterative  models  such  as  the  spiral  development 
model;  formal  acquisition  models  (e.g.,  as  defined  in  DoD  5000.2  2013);  or  less 
formal  acquisition  models  (e.g.,  quick  reaction  capability  or  internal  research  and 
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development  (IR&D)  models). 

3.1.2.  Concept  Definition  A  set  of  core  technical  activities  of  systems  engineering  in 
which  the  problem  space  and  the  needs  of  the  stakeholders  are  closely  examined 
(BKCASE  Editorial  Board  2016).  This  consists  of  analysis  of  the  problem  space, 
business  or  mission  analysis,  and  the  definition  of  stakeholder  needs  for  required 
services. 

3.1.3.  System  Definition:  A  set  of  core  technical  activities  of  systems  engineering, 
including  the  activities  that  are  completed  primarily  in  the  front-end  portion  of  the 
system  design.  (BKCASE  Editorial  Board  2016)  This  consists  of  the  definition  of 
system  requirements,  the  design  of  one  or  more  logical  and  physical 
architectures,  and  analysis  and  selection  between  possible  solution  options. 

3.1.4.  System  Realization  The  activities  required  to  build  a  system,  integrate  disparate 
system  elements,  and  ensure  that  a  system  both  meets  the  needs  of  stakeholders 
and  aligns  with  the  requirements  identified  in  the  system  definition  stage  (BKCASE 
Editorial  Board  2016).  This  includes  implementation  as  well  as  integration, 
verification,  and  validation  (IV&V). 

3.1.5.  System  Deployment  and  Use:  A  set  of  core  technical  activities  of  systems 
engineering  to  ensure  that  the  developed  system  is  operationally  acceptable  and 
that  the  responsibility  for  the  effective,  efficient,  and  safe  operations  of  the 
system  is  transferred  to  the  owner  (BKCASE  Editorial  Board  2016).  Considerations 
for  deployment  and  use  must  be  included  throughout  the  system  lifecycle. 
Activities  within  this  phase  include  deployment,  operation,  maintenance,  and 
logistics. 

3.1.6.  Product  and  Service  Life  Management:  Deals  with  the  overall  lifecycle  planning 
and  support  of  a  system  (BKCASE  Editorial  Board  2016).  The  life  of  a  product  or 
service  often  spans  a  considerably  longer  period  of  time  than  the  time  required  to 
design  and  develop  the  system.  This  stage  includes  service  life  extension, 
updates,  upgrades,  and  modernization,  and  disposal  and  retirement. 

3. 2. Systems  Engineering  Management:  Managing  the  resources  and  assets  allocated  to 
perform  systems  engineering,  often  in  the  context  of  a  project  or  a  service,  but 
sometimes  in  the  context  of  a  less  well-defined  activity.  Systems  engineering 
management  is  distinguished  from  general  project  management  by  its  focus  on  the 
technical  or  engineering  aspects  of  a  project  (BKCASE  Editorial  Board  2016).  The  topics 
contained  in  the  Systems  Engineering  Management  category  are  defined  below: 

3.2.1.  Planning:  Planning  involves  developing  and  integrating  technical  plans  to  achieve 
the  technical  project  objectives  within  the  resource  constraints  and  risk 
thresholds.  This  involves  the  success-critical  stakeholders  to  ensure  that 
necessary  tasks  are  defined  with  the  right  timing  in  the  lifecycle  in  order  to 
manage  acceptable  risks  levels,  meet  schedules,  and  avoid  costly  omissions 
(BKCASE  Editorial  Board  2016). 
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3.2.2.  Risk  Management:  Organized,  analytic  process  to  identify  what  might  cause  harm 
or  loss  (identify  risks);  to  assess  and  quantify  the  identified  risks;  and  to  develop 
and,  if  needed,  implement  an  appropriate  approach  to  prevent  or  handle  causes 
of  risk  that  could  result  in  significant  harm  or  loss  ( ISO/I  EC/I  EEE  24765:2010  - 
SEVocab). 

3.2.3.  Configuration  Management:  A  discipline  applying  technical  and  administrative 
direction  and  surveillance  to:  identify  and  document  the  functional  and  physical 
characteristics  of  a  configuration  item,  control  changes  to  those  characteristics, 
record  and  report  change  processing  and  implementation  status,  and  verify 
compliance  with  specified  requirements  (ISO/IEC/IEEE  24765:2010  -  SEVocab). 

3.2.4.  Assessment  and  Control  This  process  involves  determining  and  initiating  the 
appropriate  handling  strategies  and  actions  for  findings  and/or  discrepancies  that 
are  uncovered  in  the  enterprise,  infrastructure,  or  lifecycle  activities  associated 
with  the  project  (BKCASE  Editorial  Board  2016). 

3.2.5.  Quality  Management:  Whether  a  systems  engineer  delivers  a  product,  a  service, 
or  an  enterprise,  the  deliverable  should  meet  the  needs  of  the  customer  and  be 
fit  for  use.  Such  a  deliverable  is  said  to  be  of  high  quality.  The  process  to  assure 
high  quality  is  called  quality  management  (BKCASE  Editorial  Board  2016). 

3.3.SE  Methods,  Processes,  and  Tools:  A  systems  engineering  method  is  set  of  activities, 
methods,  practices,  and  transformations  that  people  use  to  develop  and  maintain 
systems  and  associated  products  (SEI  2007).  Processes  generally  refer  to  the  specific 
guidelines  an  organization  develops  for  implementing  systems  engineering  methods; 
tools  refer  to  software  programs  that  are  designed  to  support  systems  engineering 
activities.  The  topics  contained  in  the  SE  Methods,  Processes,  and  Tools  category  are 
outlined  below: 

3.3.1.  Balance  and  Optimization  Specialty  engineers  often  focus  on  the  details  and 
optimization  of  their  specific  components  of  the  system,  but  that  optimization  of 
individual  components  often  leads  to  a  less-than-optimal  system  solution. 
Systems  engineers,  therefore,  have  to  be  able  to  balance  the  desire  for 
component  optimization  with  the  optimization  for  the  system  overall,  which 
often  requires  sub-optimization  for  one  or  more  components. 

3.3.2.  Modeling  and  Simulation:  A  model  is  a  simplified  representation  of  a  system  at 
some  particular  point  in  time  or  space  intended  to  promote  understanding  of  the 
real  system.  A  simulation  is  the  manipulation  of  a  model  in  such  a  way  that  it 
operates  on  time  or  space  to  compress  it,  thus  enabling  one  to  perceive  the 
interactions  that  would  not  otherwise  be  apparent  because  of  their  separation  in 
time  or  space  (Bellinger  2004).  This  topic  represents  and  individual's  ability  to 
understand  and  perform  modeling  and  simulation;  this  understanding  is  more 
fundamental  than  the  ability  to  use  software  tools  that  support  modeling  and 
simulation. 

3.3.3.  Development  Processes:  Each  organization  has  its  own  processes  that  govern  the 
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development  of  systems.  It  is  important  for  systems  engineers  to  understand 
generic  systems  engineering  processes,  but  also  the  specific  processes  being  used 
for  development  within  the  organization  or  domain. 

3.3.4.  Systems  Engineering  Tools:  Systems  engineers  need  to  be  able  to  utilize  tools  to 
support  overall  system  development  and  to  perform  the  systems  engineering 
development  process.  Tools  may  include  requirements  management  and  other 
tools  that  assist  with  project  life  management  (PLM). 

3.4. Systems  Engineering  Trends:  Current  and  future  trends  in  performing  Systems 

Engineering,  that  modify  the  way  systems  are  developed. 

3.4.1.  Complexity:  Complexity  of  a  system  is  generally  understood  to  exist  not  in  a 
higher  order  scale  or  level  of  a  system,  but  rather  in  the  higher  order  of 
interactions  between  system  elements,  disciplines,  or  technologies,  and  the 
properties  that  emerge  out  of  these  interactions  that  are  not  present  in  the 
individual  elements.  One  categorization  of  complexity  includes  structural 
complexity,  dynamic  complexity,  and  socio-political  complexity;  while  another 
identifies  two  kinds  of  complexity:  disorganized  complexity  and  organized 
complexity  (SEBoK  authors  2016). 

3.4.2.  Model  Oriented  Systems  Engineering:  Model  Based  Systems  Engineering  (MBSE) 
is  a  theme  that  is  being  increasingly  adopted  in  systems  engineering,  where 
models  are  used  to  describe  various  elements  of  systems  and  the  systems 
development  process.  Model  Oriented  Systems  Engineering  (MOSE)  goes  beyond 
MBSE,  and  presents  a  holistic  model-based  approach  that  integrates  operational, 
technical,  programmatic  and  business  dimensions  as  well. 

3.4.3.  Systems  Engineering  Analytics:  The  increasing  ability  to  collect,  store,  analyze, 
and  gain  insights  from  large  quantities  of  data  has  significantly  improved  the  area 
of  analytics  in  general.  This  perspective  can  also  be  applied  to  systems 
engineering,  where  complex  phenomena  within  systems  and  systems 
development  can  be  measured  and  analyzed. 

3.4.4.  Agile  Systems  Engineering:  The  shrinking  of  systems  engineering  development 
lifecycles,  increasingly  uncertain  and  rapidly  changing  requirements  and 
operational  environments  of  modern  systems,  has  led  to  the  development  and 
adoption  of  agile  systems  engineering  approaches. 

The  Helix  team  determined  that  as  these  are  specific  applications  of  systems  engineering,  they 
fit  within  Proficiency  Area  3;  the  Helix  team  has  labeled  these  "trends".  Rather  than  selecting  a 
single  trend,  the  Helix  team  determined  that  creating  a  category  for  "Systems  Engineering 
Trends"  was  more  reasonable  than  creating  categories  for  each  potential  trend.  The  trends 
listed  in  3.4  are  consistent  with  some  of  the  areas  of  interest  expressed  across  a  number  of 
organizations  in  the  Helix  sample.  Additional  trends  could  be  added  as  they  become  more 
prominent  in  the  systems  engineering  community. 
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Figure  49  illustrates  the  distribution  for  Systems  Engineering  Discipline  responses.  As  it  can  be 
observed  more  than  half  of  systems  engineers  identified  their  Systems  Engineering  Discipline 
skills  to  be  between  7  and  8.  Also,  one  in  four  systems  engineers  believe  their  skills  are  between 
9  and  10.  None  of  the  participants  believe  that  their  skills  are  underdeveloped  since  none 
graded  himself  with  a  grade  of  1  or  2. 
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Figure  49.  Proficiency  distribution  for  Systems  Engineering  Discipline  responses 


Figure  50  illustrates  that  more  than  three-quarters  of  systems  engineers  who  responded  7  or  8 
to  the  Systems  Engineering  Discipline  proficiency  model  have  been  exposed  to  the  component 
and  system  level.  Also,  only  67%  of  participants  have  been  exposed  to  the  subsystem  level. 
Lastly,  17%  of  those  interviewed  have  been  exposed  to  the  Platform/Systems  of  System  type  of 
system. 
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Figure  50.  Distribution  for  system  types  for  individuals  with  the  highest  proficiency  self-assessments  in  Systems 
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In  regard  to  the  type  of  organization,  92%  of  engineers  who  responded  7  or  8  to  Domain  and 
Operational  Context  have  experience  in  the  industry.  One  in  four  participants  (25%)  have  been 
involved  in  government  of  organizations.  Also,  17%  of  participants  have  Academic  experience. 
Figure  51  illustrates  the  organization  type  for  those  participants  who  answer  7  or  8. 
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Figure  51.  Distribution  for  organization  types  for  individuals  with  the  highest  proficiency  self-assessments  in 

Systems  Engineering  Discipline 

Figure  52  denotes  the  most  frequent  roles  for  individuals  who  graded  themselves  7  or  8.  As  it 
can  be  observed,  most  participants  played  the  role  of  Coordinator  (93%).  Verification  and 
Validation  (79%)  as  well  as  Detailed  Designer  (79%)  are  the  second  most  frequent  roles.  The 
least  played  role  is  Instructor  or  Teacher  with  only  (14%). 
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Figure  52.  Roles  distribution  for  individuals  with  the  highest  proficiency  self-assessments  in  Systems  Engineering 

Discipline 
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5.1.5.  Systems  Mindset 


The  fourth  proficiency  area  is  Systems  Mindset,  which  is  primarily  focused  on  patterns  of 
thinking,  perceiving,  and  approaching  a  task  that  are  particularly  relevant  to  systems  engineers. 
The  categories  included  in  this  area  are: 

4.1.  Big-Picture  Thinking:  Also  referred  to  as  'systems  thinking'  and  'holistic  thinking',  this 
includes  the  ability  to  step  back  and  take  a  broader  view  of  the  problem  at  hand;  this  is 
an  important  and  essential  characteristic  of  systems  engineers.  'Big-picture'  could  refer 
to  a  broader  perspective  along  many  different  dimensions:  the  system  as  a  whole 
including  interfaces  and  integration,  and  not  limited  to  any  sub-system  or  component; 
the  system  while  in  operation,  and  its  interactions  with  other  systems  and  the  operating 
environment;  the  entire  lifecycle  of  the  system,  and  not  limited  to  the  current  stage  of 
the  system;  the  development  program  in  the  context  of  the  organization  and  all  its 
other  development  programs;  the  end  goal  or  solution  to  the  problem  at  hand;  the 
perspectives  of  different  stakeholders;  and  the  technical  as  well  as  business 
perspectives.  A  systems  engineer  is  usually  the  person  to  bring  this  broader  perspective, 
while  classic  engineers  and  subject  matter  experts  often  tend  to  be  narrowly  focused  on 
their  area  of  interest.  Systems  engineers  are  not  only  called  to  provide  this  big-picture 
perspective  themselves,  but  to  also  enable  others  to  see  this  bigger  picture. 

4.2.  Paradoxical  Mindset:  The  ability  to  hold  and  balance  seemingly  opposed  views,  and 
being  able  to  move  from  one  perspective  to  another  appropriately.  Typically,  an 
engineer  may  hold  one  view  or  the  other,  but  rarely  both.  By  having  this  paradoxical 
mindset,  a  systems  engineer  contributes  value  that  is  not  usually  expected  from  others. 
The  opposing-concept  pairs  are: 

4.2.1.  Big-Picture  Thinking  and  Attention  to  Detail:  Big-picture  thinking  provides  the 
broader  higher-level  perspective;  at  the  same  time,  a  systems  engineer  is  also 
required  to  pay  attention  to  the  details  of  how  things  work  and  how  they  come 
together  in  a  system. 

4.2.2.  Strategic  and  Tactical:  Systems  engineers  need  to  be  strategic,  focused  on  the 
end  result  of  'vision'  for  the  system,  but  also  need  to  handle  the  tactical  day-to- 
day  activities  and  decisions  required  to  reach  that  vision.  They  must  also  be  able 
to  appreciate  "how  what  is  done  today  is  going  to  affect  things  downstream".  A 
related  concept  pair  is  the  ability  to  envision  long-term  issues  but  at  the  same 
time,  have  the  desire  for  closure  with  the  current  situation  in  order  to  move  on. 

4.2.3.  Analytic  and  Synthetic:  A  big-picture  perspective  may  be  associated  with  the 
ability  to  be  synthetic,  and  to  be  able  to  bring  together  and  integrate  different 
pieces  of  a  puzzle.  However,  a  systems  engineer  also  needs  to  be  analytic  and  to 
be  able  to  break  down  the  big  picture  into  smaller  pieces  on  which  others  can 
focus  and  work.  To  do  this  effectively,  a  systems  engineer  needs  to  be  able  to 
operate  at  multiple  levels  (e.g.,  component,  sub-system,  system,  system-of- 
systems)  and  multiple  dimensions  (e.g.,  various  technical  disciplines  and 
stakeholder  perspectives). 
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4.3.  Ada pta bility :  The  overall  ability  to  deal  with  ambiguity  and  uncertainty,  this  involves  the  abilities 
to  be  open-minded,  understand  multiple  disciplines,  deal  with  challenges,  and  the  ability  to  take 
rational  risks.  By  definition,  experts  possess  proficiency  in  a  specific  area,  which  is  their  'comfort 
zone';  and  they  typically  do  not  prefer  going  outside  that  circle  or  comfort  zone.  Such  experts 
provide  value  to  the  organization  by  contributing  their  expertise  in  those  focused  areas. 
However,  systems  engineers  tend  to  show  an  ability  to  broaden  their  comfort  zones,  and  go 
beyond  their  current  boundaries  and  they  are  also  comfortable  doing  this. 

4.4.  Abstraction:  The  ability  to  filter  out  and  understand  the  critical  bits  of  information  at  the 
right  ievei  and  to  make  relevant  inferences.  And  even  with  that  filtered  information, 
systems  engineers  need  to  know  when  to  use  or  not  use  pieces  of  information.  Such 
abstraction  also  enables  systems  engineers  to  connect  and  extract  meaning  from 
different  streams  of  information;  for  example,  to  tie  together  information  that  subject 
matter  experts  of  two  different  disciplines  are  providing. 

4.5.  Foresight  and  Vision:  The  ability  to  foresee  the  remaining  lifecycle  of  the  system,  the 
impact  of  current  decisions,  and  to  mentally  simulate  possible  scenarios.  Every  decision 
or  change  is  likely  to  have  an  impact  beyond  the  current  confines  of  time  or  space. 
Particularly  in  early  stages  of  a  system  lifecycle,  and  in  the  development  of  a  new  or 
unfamiliar  system,  foresight  is  a  key  value  that  systems  engineers  provide. 

Figure  53  illustrates  the  distribution  for  Systems  Engineering  Mindset  responses.  As  it  can  be 
observed  slightly  less  than  half  (48%)  of  systems  engineers  identified  their  Systems  Engineering 
Mindset  skills  to  be  between  7  and  8.  Also,  more  than  one  in  three  (39%)  systems  engineers 
believe  their  skills  are  between  9  and  10.  None  of  the  participants  believe  that  their  skills  are 
underdeveloped  since  none  graded  himself  with  a  grade  of  1  or  2  or  the  range  3  or  4. 
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Figure  53.  Proficiency  distribution  for  Systems  Engineering  Mindset  responses 
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Figure  54  illustrates  that  more  than  three-quarters  of  systems  engineers  who  responded  7  or  8 
to  the  Systems  Engineering  Mindset  proficiency  model  have  been  exposed  to  the  component 
and  system  level.  Also,  only  69%  of  participants  have  been  exposed  to  the  subsystem  level. 
Lastly,  15  %  of  those  interviewed  have  been  exposed  to  the  Platform/Systems  of  System  type  of 
system. 
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Figure  54.  Distribution  for  system  types  for  individuals  with  the  highest  proficiency  self-assessments  in  Systems 

Mindset 

Figure  55  illustrates  the  organization  type  for  those  participants  who  answer  7  or  8.  93%  of 
engineers  have  experience  in  the  industry.  Less  than  30%  are  experienced  in  government 
organizations  while  only  14%  have  been  exposed  to  academia 
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Figure  55.  Distribution  for  organization  types  for  individuals  with  the  highest  proficiency  self-assessments  in 

Systems  Mindset 
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Figure  56  denotes  the  most  frequent  roles  for  individuals  who  graded  themselves  7  or  8.  As  it 
can  be  observed,  all  participants  played  the  role  of  Coordinator.  Verification  and  Validation 
(81%)  is  the  second  most  frequent  role.  Detailed  Designer  (75%)  and  Technical  Manager  (75%) 
are  both  the  third  most  popular  role.  The  least  played  role  is  Instructor  or  Teacher  with  only 
(19%). 

Roles  Played  by  Individuals  with  the  Highest  Proficiency  Self-Assessments 
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Figure  56.  Roles  distribution  for  individuals  with  the  highest  proficiency  self-assessments  in  Systems  Mindset 


5.1.6.  Interpersonal  Skills 

The  fifth  proficiency  area  is  Interpersonal  Skills.  Almost  by  definition,  systems  engineers  do  not 
just  work  by  themselves  at  their  desks  all  day  -  they  interact  with  people.  Irrespective  of  any 
formal  leadership  roles  they  may  or  may  not  play,  a  systems  engineer  is  expected  to  be 
proficient  in  a  number  of  interpersonal  skills.  While  specialty  engineers  may  be  responsible  for 
developing  specific  aspects  of  the  system,  systems  engineers  are  responsible  for  coordinating 
across  all  of  these  engineers.  Hence,  interpersonal  skills  are  more  critical  to  systems  engineers 
than  they  are  to  specialty  engineers.  The  specific  categories  contained  within  this  proficiency 
area  are  listed  below: 

5.1. Communication:  Communication  is  critical  for  systems  engineers  since  they  interact 
with  a  variety  of  people,  and  is  a  broad  category  covering  a  wide  variety  of  related  skills 
and  abilities.  Often  they  are  an  important  link  between  individuals  and  groups,  both 
internal  and  external  to  the  organization  -  most  importantly,  the  customers  and  end- 
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users  of  the  system  being  developed.  Systems  engineers  need  the  ability  to  clearly 
express  their  thoughts  and  perspectives  to  establish  a  shared  common  understanding. 

5.1.1.  Audience:  Systems  engineers  need  to  communicate  with  a  variety  of  direct  and 
indirect  audiences:  customers;  subject  matter  experts;  program  managers;  vice 
presidents;  directors;  specialty  engineers;  problem  owners;  technical  teams; 
contractors;  decision  makers;  system  testers;  and  others  working  on  or  with  the 
project. 

5.1.2.  Content:  The  variety  of  content  that  systems  engineers  need  to  communicate 
can  be  broadly  divided  into  three  types,  based  on  the  audience  they  are 
communicating  with: 

1.  Technical:  Communications  with  disciplinary  and  specialty  engineers  and 
subject  matter  experts  involve  high  technical  content.  But 
communications  of  technical  issues  to  managers,  end-users,  and  others 
who  may  not  be  interested  in  or  who  may  be  confused  by  all  the  technical 
detail,  involves  adequate  abstraction  of  the  technical  content. 

2.  Managerial:  Systems  engineers  often  provide  project  status  to  managers 
and  supervisors  and  cost-schedule  constraints  and  expectations  to 
technical  personnel. 

3.  Social:  Systems  engineers  need  to  maintain  an  amicable  environment 
within  a  team  and  to  interact  with  others  in  a  courteous  manner.  Such 
interactions  involve  communications  that  are  neither  technical  nor 
managerial  in  nature. 

5.1.3.  Mode  Communicating  the  intended  content  to  the  target  audience  is  done 
through  a  number  of  different  modes: 

1.  Oral:  This  takes  various  forms,  depending  on  the  audience  and  context.  It 
could  be  one-on-one,  or  as  part  of  a  team,  in  person,  or  remotely. 

2.  Presentation:  A  special  form  of  communications  is  the  ability  to  stand  in 
front  of  an  audience  and  to  deliver  a  presentation  using  appropriate  aids. 
Further,  during  presentations,  systems  engineers  tend  to  represent  others 
who  may  not  be  in  the  room:  they  present  customer  needs  and 
requirements  to  others  in  the  absence  of  customers,  and  they  present 
design  decisions  and  system  related  issues  to  customers  in  the  absence  of 
designers. 

3.  Writing  and  Documentation:  Written  communication  skills  are  equally 
critical  for  systems  engineers;  the  scale,  audience,  and  objective  of  the 
written  artifact  also  matter.  It  could  range  from  a  short  email  to 
communicate  status,  to  a  detailed  test  plan,  to  internal  documentation 
supporting  a  project  decision,  to  design  documents  being  submitted  for 
review. 

5.2. Listening  and  Comprehension:  The  ability  to  listen  to  others'  points  of  views  and 
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perspectives,  and  to  comprehend  and  internalize  the  message  accurately.  For  systems 
engineers,  listening  begins  with  the  customer  to  understand  their  real  needs  and  ensure 
that  these  needs  get  translated  into  requirements.  In  a  team  environment,  systems 
engineers  need  to  listen  to  the  views  and  perspectives  being  offered:  from  designers, 
subject  matter  experts,  and  others. 

5.3.Working  in  a  Team:  Systems  engineers  tend  to  be  part  of  many  teams  during  the 
lifecycle  of  the  system;  further,  systems  engineering  by  itself  is  typically  not  performed 
by  an  individual,  but  rather  by  a  team.  Hence,  team  dynamics  and  synergy  are  key  to  the 
functioning  of  a  systems  engineer. 

5.4. Influence,  Persuasion,  and  Negotiation:  It  is  critical  for  every  systems  engineer,  not  just 
those  in  formal  leadership  positions,  to  have  the  skills  needed  to  make  a  point  and  to 
successfully  obtain  buy-in.  In  many  situations,  systems  engineers  contribute  a 
perspective  that  is  different  from  that  of  others:  a  focus  on  the  overall  system  and  on 
customer's  needs.  In  such  situations,  it  requires  influence,  persuasion,  and  negotiating 
skills  for  systems  engineers  to  enable  others  to  see  the  bigger  picture  on  which  they 
need  to  focus. 

5. 5. Building  a  Social  Network:  A  systems  engineer  needs  to  be  a  'people  person',  and  build 
a  social  network  of  professional  acquaintances.  Such  a  network  becomes  a  valuable 
resource  for  systems  engineers  to  tap  into,  because  they  are  not  expected  to  know 
answers  to  all  problems,  but  rather  be  able  to  find  someone  who  has  the  expertise  and 
ability  to  solve  the  problem. 

Figure  57  illustrates  the  distribution  for  Interpersonal  Skills  responses.  As  it  can  be  observed 
74%  of  systems  engineers  identified  their  Interpersonal  skills  to  be  between  7  and  8.  Also, 
participants  who  graded  themselves  between  5  or  6  and  9  or  10  are  distributed  evenly  with 
13%  each  category.  None  of  the  participants  believe  that  their  skills  are  underdeveloped  since 
none  graded  himself  with  a  grade  of  1  or  2  or  the  range  3  or  4. 

Current  Interpersonal  Skills  Proficiency  Response 
Distribution 


100% 


1  or  2  3  or  4  5  or  6  7  or  8  9  or  10 

Proficiency  Distribution 

Figure  57.  Proficiency  distribution  for  Interpersonal  Skills  responses 
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Figure  58  illustrates  that  93%  of  systems  engineers  who  responded  7  or  8  to  the  Interpersonal 
Skills  proficiency  model  have  been  exposed  to  the  component  level.  Exposure  to  the  subsystem 
and  system  level  has  been  distributed  evenly  both  with  80%  of  the  total  number  of  participants. 
Lastly,  20  %  of  those  interviewed  have  been  exposed  to  the  Platform/Systems  of  System  type  of 
system. 
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Figure  58.  Distribution  for  system  types  for  individuals  with  the  highest  proficiency  self-assessments  in 

Interpersonal  Skills 

Figure  59  illustrates  the  organization  type  for  those  participants  who  answer  7  or  8.  88%  of 
engineers  have  experience  in  the  industry.  Also,  35%  are  experienced  in  government 
organizations  while  only  6%  have  been  exposed  to  academia. 
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Figure  59.  Distribution  for  organization  types  for  individuals  with  the  highest  proficiency  self-assessments  in 

Interpersonal  Skills 


Report  No.  SERC-2018-TR-101-C 


90 


January  16,  2018 


Figure  60  denotes  the  most  frequent  roles  for  individuals  who  graded  themselves  7  or  8.  As  it 
can  be  observed,  all  participants  played  the  role  of  Coordinator.  Requirements  Owner, 
Verification  and  Validation  and  Technical  Manager  are  the  second  most  played  roles  with 
(82%)The  least  played  role  is  Instructor  or  Teacher  with  only  (18%). 
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Figure  60.  Roles  distribution  for  individuals  with  the  highest  proficiency  self-assessments  in  Interpersonal  Skills 


5.1.7.  Technical  Leadership 

The  sixth  and  final  Atlas  proficiency  area  is  Technical  Leadership.  It  is  common  and  natural  for 
systems  engineers  to  play  leadership  roles  at  many  levels  within  an  organization.  The  specific 
categories  contained  within  Technical  Leadership  are  listed  below: 

6.1. Building  and  Orchestrating  a  Diverse  Team:  The  ability  to  identify,  build,  and  effectively 
guide  or  coach  a  team  comprising  individuals  with  diverse  expertise,  perspectives,  and 
personalities.  While  organizational  titles  may  vary,  it  is  most  often  a  systems  engineer 
who  is  the  leader  of  the  team  that  is  charged  with  delivering  the  system.  The  systems 
engineer  needs  to  fully  know  each  of  the  team  members:  their  strengths,  weaknesses, 
capacities,  capabilities,  limitations,  personalities,  expertise,  and  working  styles.  The 
systems  engineer  plays  the  roles  of  coach,  guide,  and  teacher  to  develop  the  team's 
capabilities  and  to  orchestrate  it  to  perform  the  required  tasks.  Individual  leadership 
styles  could  vary,  but  the  overall  objective  of  is  to  empower  the  team,  to  instill 
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confidence,  and  to  help  them  to  deliver  the  solution  and  to  be  successful.  Another  key 
aspect  of  handling  a  team  is  the  ability  to  delegate  -  the  leader  needs  to  build  enough 
trust  in  the  team  to  be  able  to  delegate  with  confidence. 

6.2.  Balanced  Decision  Making  and  Rational  Risk  Taking:  Solving  a  problem  requires  a 
systems  engineer  to  take  a  number  of  balanced  decisions  considering  a  variety  of 
factors,  constraints,  perspectives,  and  objectives;  as  well  as  the  implications  of  these 
decisions  and  their  scope  of  impact.  An  additional  challenge  is  that  most  often,  all  the 
required  information  may  not  be  readily  available.  The  ability  to  make  such  decisions 
also  requires  the  systems  engineer  to  be  comfortable  in  dealing  with  ambiguity  and 
uncertainty  and  to  be  able  to  take  rational,  calculated  risks. 

6.3.  Guiding  Diverse  Stakeholders:  This  includes  the  ability  to  manage  all  the  internal  and 
external  stakeholders,  and  to  keep  the  team  focused  on  their  needs,  especially  those  of 
the  end  user  or  customer.  The  systems  engineer  is  uniquely  positioned  to  interact  with 
many  stakeholders  of  the  system  -  both  external  and  internal  to  the  organization.  Being 
this  "touch  point"  person,  the  systems  engineer  needs  to  deal  with  multiple 
personalities,  behaviors,  organizations,  and  cultures. 

6.4.  Conflict  Resolution  and  Barrier  Breaking:  Conflicts  are  bound  to  rise  in  a  variety  of 
scenarios  -  within  the  team;  within  the  organization  -  between  the  technical  side  and 
business  side  of  the  organization;  as  well  as  with  outside  the  organization.  As  a  leader, 
the  systems  engineer  must  resolve  these  conflicts  while  keeping  the  system  goals  in 
mind.  In  some  cases,  conflicts  arise  due  to  the  existence  of  barriers,  which  may  be 
related  to  the  organizational  culture,  processes,  team  personalities,  or  other  situations 
that  could  prevent  an  individual  or  team  from  getting  their  work  done.  The  systems 
engineer  needs  the  ability  to  break  these  barriers. 

6.5.  Business  and  Project  Management:  Depending  on  the  way  roles  and  titles  are  defined 
within  an  organization,  a  systems  engineer's  responsibilities  may  overlap  with  what  may 
be  seen  as  'project  management'  responsibilities.  Even  if  there  is  no  overlap,  a  systems 
engineer  is  expected  to  handle  a  variety  of  business  and  project  management  activities 
including  accounting,  budget,  cost  estimation,  schedule,  work  breakdown,  and  profit. 
The  systems  engineer  must  also  be  cognizant  of  the  business  impact  of  technical 
decisions  that  are  taken. 

6.6.  Establishing  Technical  Strategies:  Systems  engineers  must  fearlessly  and  creatively 
guide  the  establishment  of  new  capabilities  and  transformations  (e.g.,  to  migrate  to 
Cloud  Infrastructure,  or  to  establish  a  new  information  service  architecture,  or  to  enable 
transition  to  a  DEVOPS  model).  Senior  systems  engineers  need  to  be  able  to  support  the 
organization  in  the  development  of  overarching  technical  directions  and  support  the 
development  of  technical  roadmaps  that  establish  a  vision  to  support  the  strategy. 

6.7.  Enabling  Broad  Portfolio-Level  Outcomes:  Along  with  the  development  of  strategies  to 
guide  strategic  technical  investments,  systems  engineers  should  provide  the  broad 
perspective  necessary  to  enable  technical  success  not  only  on  individual  projects  but 
across  projects  and  programs  to  enable  advancement  across  the  technical  portfolio. 
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Note  that  Categories  6.6  and  6.7  are  new  to  Atlas  1.0.  These  categories  speak  not  just  to 
technical  leadership  within  teams,  but  also  to  technical  leadership  within  an  organization. 
These  were  not  initially  included  because  they  were  heard  clearly  at  few  organizations  in  the 
Helix  sample.  However,  the  Helix  team  hopes  that  Atlas  will  be  relevant  not  only  today  but  in 
the  future.  To  this  end,  community  outreach,  implementation  work,  and  literature  review  in 
2016  has  focused  on  ensuring  that  the  proficiency  model  will  be  relevant  for  future  systems 
engineers  as  well.  Categories  6.6  and  6.7  speak  to  a  vision  of  roles  that  systems  engineers 
should  play  in  future  (e.g.  INCOSE  Vision  2025,  2014)  and  aligns  with  proficiencies  already 
expected  of  senior  systems  engineers  in  some  organizations. 

Figure  61  illustrates  the  distribution  for  Systems  Engineering  Mindset  responses.  As  it  can  be 
(60%)  of  systems  engineers  identified  their  Technical  Leadership  skills  to  be  between  7  and  8. 
Also,  21%  stated  that  their  personal  skills  are  ranked  between  5  or  6.  17%  systems  engineers 
believe  their  skills  are  between  9  and  10.  None  of  the  participants  believe  that  their  skills  are 
underdeveloped  since  none  graded  himself  with  a  grade  of  1  or  2  or  the  range  3  or  4. 


Current  Domain  and  Operational  Context  Proficiency  Response 

Distribution 


1  or  2  3  or  4  5  or  6  7  or  8  9  or  10 

Proficiency  Distribution 

Figure  61.  Proficiency  distribution  for  Technical  Leadership 

Figure  62  illustrates  that  more  than  three-quarters  of  systems  engineers  who  responded  7  or  8 
to  the  Technical  Leadership  proficiency  model  have  been  exposed  to  the  component  and 
system  level.  Also,  33%  Platform/Systems  of  System  type  of  system. 
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System  Types  for  individuals  with  the  Highest  Proficiency  Self- 

Assessmnets 


100% 


Component  Subsystem  System  Platform/  System 

of  Systems 


System  Type 


Figure  62.  Distribution  for  system  types  for  individuals  with  the  highest  proficiency  self-assessments  in  Technical 

Leadership 

Figure  63  illustrates  the  organization  type  for  those  participants  who  answer  7  or  8.  82%  of 
engineers  have  experience  in  the  industry  and  27%%  are  experienced  in  government 
organizations  while  only  9%  have  been  exposed  to  academia 

Organization  Types  for  Individuals  with  the  Highest 
Proficiency  Self-Assessments 


Government  Industry  Academia 


Organization  Type 


Figure  63.  Distribution  for  organization  types  for  individuals  with  the  highest  proficiency  self-assessments  in 

Technical  Leadership 

Figure  64  denotes  the  most  frequent  roles  for  individuals  who  graded  themselves  7  or  8.  As  it 
can  be  observed,  all  participants  played  the  role  of  Coordinator.  Detailed  Designer  (91%)  is  the 
second  most  frequent  role.  Requirements  Owner,  Verification  and  Validation,  Customer 
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Percentage 


Interface  and  Technical  Manager  all  occupy  the  third  position  with  (73%).  The  least  played  role 
is  Instructor  or  Teacher  with  only  (18%). 


Roles  Played  by  Individuals  with  the  Highest  Proficiency  Self-Asessments 

100% 

80% 
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0% 
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Figure  64.  Roles  distribution  for  individuals  with  the  highest  proficiency  self-assessments  in  Technical  Leadership 
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6.  Answering  Frequently  Asked  Questions  About  Career  Paths 


Whenever  Atlas  is  presented  to  the  community,  there  are  several  questions  that  frequently  are 
asked  about  career  paths.  Though  many  of  these  are  answered  in  the  "Interpreting  the  Results" 
sections  above,  the  Helix  team  provides  brief  answers  here  for  those  who  prefer  a  briefer 
summary.  Each  section  references  the  appropriate  analyses;  readers  are  encouraged  to  review 
the  details  if  they  have  questions. 

Did  we  answer  your  questions?  If  not,  please  contact  the  Helix  team  at  helix@stevens.edu. 


6.1.  SE  Practitioners:  Does  it  Matter  How  I  Move  through  the  System  Lifecycle? 

The  Helix  team  gets  this  question  frequently  and  often,  members  of  the  community  will  share 
their  opinions  on  this  quite  vehemently.  The  truth,  though,  is  that  despite  examining  the  career 
paths  of  178  systems  engineers,  no  one  clear  path  or  even  handful  of  paths  emerged  as  the 
"right"  way  to  move  through  the  systems  lifecycle.  Section  3.2.1  provides  detailed  analysis  of 
the  ways  systems  engineers  in  the  sample  have  moved  through  the  lifecycle;  Section  4.2.1  for 
chief  systems  engineers  (CSEs)  in  the  sample. 

The  most  commonly-recommended  ways  to  move  through  the  lifecycle  from  senior  systems 
engineers  interviewed  were  from  "front-to-back"  or  "back-to-front".  The  idea  was  that  either 
way  would  allow  an  individual  to  experience  the  full  lifecycle  and  particularly  highlight  the 
relationships  between  the  lifecycle  stages.  However,  almost  none  of  the  systems  engineers  in 
the  Helix  dataset  actually  moved  through  the  lifecycle  in  these  exact  ways. 

Here  is  the  bottom  line  of  the  analysis  on  lifecycle  stages: 

•  Variety  is  important.  In  terms  of  growth,  there  are  no  CSEs  in  the  sample  that  have 
experiences  in  fewer  than  four  lifecycle  stages.  It  was  stated  repeatedly  throughout  the 
Helix  interviews  that  someone  must  see  most  of  the  lifecycle  to  grow  as  a  systems 
engineer.  The  specific  order,  based  on  the  data  available,  appears  less  important  than 
the  variety. 

•  Abstraction  is  critical.  Part  of  what  moving  through  the  systems  engineering  lifecycle 
does  for  systems  engineers  is  it  helps  them  identify  patterns  and  points  of  integration 
between  the  different  lifecycle  phases.  The  more  effective  systems  engineers  are  better 
at  identifying  these  patterns  -  or  abstracting  patterns  from  their  experiences  -  in  a  way 
that  can  inform  them  for  new  experiences. 
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6.2.  SE  Practitioners:  How  Can  I  Figure  Out  if  I  am  Doing  the  Right  Things? 

Another  common  question  both  in  the  Helix  interviews  and  when  Helix  is  presented  publicly  is, 
"Am  I  doing  the  right  things  to  grow  as  a  systems  engineer?"  It  is  an  astute  question  that 
illustrates  these  individual's  desire  for  improved  self-awareness  (a  critical  enabling  personality 
characteristic). 

As  with  many  questions  in  the  systems  engineering  world,  the  answer  to  this  question  is,  "It 
depends."  It  depends  on  how  you  are  looking  to  grow  and  what  your  targeted  end  state  is  and 
it  depends  on  when  you  are  hoping  to  reach  this  state.  An  individual  with  a  career  path 
exposing  them  to  two  phases  of  the  lifecycle  and  only  three  systems  engineering  roles  may  be 
doing  exactly  the  right  things  to  move  from  a  junior  systems  engineer  focused  on  requirements 
to  a  mid-level  systems  engineer  focused  on  analysis  in  the  next  three  years.  However,  if  that 
same  individual  is  targeting  a  position  as  a  CSE  in  the  next  three  years,  then  he  or  she  would  be 
decidedly  offtrack. 

The  key  questions  you  must  ask  yourself  to  answer  this  question  are: 

•  What  is  it  I  am  hoping  to  achieve?  What  is  the  position  you  want  to  grow  into?  If  not  a 
specific  position,  what  are  the  areas  where  you  are  hoping  to  grow?  If  you  can  not 
answer  these  questions,  then  "on  track"  has  little  meaning. 

•  What  is  your  career  path  now?  This  document  provides  an  overview  of  career  path 
analysis  and  the  companion  Atlas  1.1  Implementation  Guide  provides  considerably  more 
detail  on  how  to  create  your  own  career  path  assessment  and  target  states  for 
proficiencies.  Without  the  understanding  of  where  you  are  now  and  how  you  go  here,  it 
is  impossible  to  determine  whether  or  not  you  are  on  an  appropriate  path  for  growth. 

•  How  does  your  career  path  compare  to  that  of  others?  Sections  3  and  4  of  this 
document  provide  a  number  of  patterns  against  which  an  individual  can  begin  this 
analysis.  Other  good  approaches  are  to  discuss  this  with  your  supervisor  or  mentor  - 
who  can  help  you  by  providing  their  own  insights  into  your  career  path  -  or  if  you  have  a 
specific  target  position  in  mind,  talk  with  individuals  in  that  position  and  find  the  gaps 
between  what  they  did  to  get  there  and  what  you  have  already  done. 

Perhaps  the  most  important  step  of  this  is  not  just  to  know  "where  you  are"  but  also  to  have  a 
plan  on  getting  to  where  you  want  to  go.  (See  6.3  below) 


6.3.  SE  Practitioners:  How  do  I  figure  Out  What  I  Should  Do  Next? 

As  with  Question  6.2,  a  critical  aspect  of  answering  this  question  is  asking  yourself  where  you 
want  to  go.  For  some,  this  is  actually  the  hardest  part  of  figuring  out  where  to  go  next.  Usually 
within  your  current  organization,  you  can  find  a  manager,  supervisor,  mentor,  or  senior  systems 
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engineer  who  can  help  you  understand  what  is  possible  within  your  organization.  Knowing  what 
is  possible  outside  your  organization  is  a  little  more  difficult,  but  the  patterns  highlighted  in 
Sections  3  and  4  of  this  guide  might  give  you  some  useful  indicators. 

Once  you  have  done  the  hard  work  of  determining  where  you  want  to  go  -  and  have  hopefully 
done  a  gap  analysis  of  that  compared  to  where  you  are  now  (see  Question  6.2)  -  you  have  a 
sense  of  what  needs  to  change  to  enable  you  to  grow.  The  question  then  becomes,  "What  is 
the  right  way  to  address  this?" 

In  Section  5,  there  are  many  patterns  highlighted  for  individuals  who  grew  in  terms  of  particular 
proficiencies,  which  can  be  very  useful  here.  For  example,  if  you  have  identified  that  you  want 
to  grow  in  "Systems  Mindset",  for  example,  you  can  compare  what  you  have  done  now  with 
the  career  paths  of  individuals  in  the  sample  who  had  the  highest  self-assessments  of 
proficiency  in  this  area.  Look  at  the  patterns  in  terms  of  roles,  lifecycle  exposure,  etc.  If  you 
notice  that  there  roles  commonly  played  by  these  individuals  that  you  have  never  played,  that 
is  an  indicator  that  you  should  seek  opportunities  to  play  these  roles.  Likewise  for  the  other 
career  patterns  analyzed,  such  as  education  and  training. 

Note  that  this  does  not  guarantee  you  success,  but  in  general  systems  engineers  in  the  Helix 
sample  reported  that  when  in  doubt,  adding  diversity  to  your  experiences  can  not  be  a 
problem. 


6.4.  SE  Leaders:  How  Do  I  Use  This  Data  to  Help  My  Current  Systems  Engineers? 

Every  leader  of  systems  engineers  the  Helix  team  has  worked  with  wants  to  know  the  answer  to 
this  question.  They  are  proud  of  the  work  and  abilities  of  their  systems  engineering  workforce  - 
but  always  aware  that  they  can  get  better  at  what  they  do.  Leaders  want  to  know  how  to  do 
this. 

There  are  several  ways  that  Atlas  can  help  with  this: 

•  Assessing  where  your  workforce  is.  Some  organizations  already  have  a  sense  of  this  as 
they  have  internal  competency  models  and  methods  for  evaluation  that  impact  those. 
But  for  most  organizations  in  the  Helix  dataset,  leaders  had  qualitative  insights  into  this 
but  no  data  to  support  it.  Using  the  Atlas  tools  to  assess  how  systems  engineers  are 
doing  in  terms  of  their  roles  and  proficiencies  is  important.  (See  the  Atlas  1.1 
Implementation  Guide  for  specific  guidance  on  how  to  do  this.) 

•  Assessing  where  your  organization  is.  Just  as  important  as  knowing  the  skills  and 
abilities  of  the  workforce  itself  is  assessing  the  context  in  which  the  organization  works. 
Atlas  assesses  a  number  of  variables  in  this  area,  from  specifics  such  as  how  the 
organization  defines  systems  engineering  and  rewards  systems  engineers,  to  the  specific 
training  and  educational  programs  to  support  systems  engineers,  to  more  general 
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factors  such  as  organizational  culture.  One  of  the  most  consistent  findings  in  the  Helix 
project  is  that  an  organization  can  have  the  most  skilled  workforce  in  the  world,  but  if 
the  organizational  environment  is  not  supportive  of  systems  engineering,  they  will 
struggle  to  be  effective.  Understanding  where  your  organization  stands  is  critical  an 
understanding  what  you  can  do  to  help. 

•  Identifying  the  roadblocks.  With  the  results  of  the  assessments  described  above,  your 
organization  should  have  enough  information  to  begin  identifying  areas  of  concern. 
Perhaps  there  are  proficiency  areas  in  which  the  workforce  overall  tends  to  be  less 
proficient  than  desire.  Perhaps  there  are  systems  engineering  roles  identified  in  Atlas 
that  are  not  performed  in  your  organization.  Or  perhaps  you  realize  that  the  way  you 
award  employees  is  antithetical  to  good  systems  engineering.  (This  has  been  the  case  in 
several  organizations.)  Whatever  the  issues,  having  identified  them  gives  you  a  place  to 
start. 

For  some  issues.  Atlas  can  only  take  you  so  far.  If  you  have  identified  major  cultural  issues, 
consulting  an  organizational  physiologist  is  likely  a  better  move  than  poring  over  the  Helix  data. 
But  if,  for  example,  one  of  the  issues  is  that  systems  engineers  are  frustrated  because  they  have 
no  clear  guidance  on  career  paths  or  are  not  aware  of  training  opportunities,  these  are  areas 
where  the  course  ahead  is  relatively  clear.  The  Helix  data  can  provide  additional  insights  in 
these  and  other  areas.  See  the  Atlas  1.1  Implementation  Guide  for  specifics. 


6.5.  SE  Leaders:  How  Do  I  Use  This  Data  to  Identify  New  Systems  Engineers? 

This  is  a  great  question,  and  one  the  Helix  team  hears  frequently.  For  this,  examining  the  career 
paths  of  self-identified  systems  engineers  is  less  helpful  than  turning  to  the  interview  data.  One 
exception,  though,  is  to  note  patterns  in  certain  undergraduate  programs  that  were  frequently 
reported  as  being  a  "good  background"  for  growing  individuals  fresh  out  of  undergrad  into 
systems  engineers.  The  two  that  were  heard  most  frequently  were  aerospace  engineering  and 
biomedical  engineering.  In  both  instances,  the  focus  on  engineering  around  a  particular  type  of 
system  meant  that  individuals  were  exposed  to  several  classic  engineering  disciplines  as  well  as 
integration  concerns  and  how  system  characteristics  such  as  weight  or  power  consumption 
could  impact  the  overall  system.  These  degrees  provided  not  only  a  background  in  the 
application  area  (aligning  with  System's  Domain  and  Operational  Context)  but  also  primed  the 
individuals  for  Big-Picture  Thinking. 

Outside  of  educational  indicators,  systems  engineering  leaders,  managers,  and  mentors 
reported  looking  for  some  specific  indicators  when  trying  to  identify  systems  engineers: 

•  Big  Picture  Thinking.  The  main  indicators  described  for  this  included  asking  "why" 
questions  and  demonstrating  interest  in  and  understanding  of  interfaces,  whether 
technical  or  interpersonal.  This  can  also  be  an  indicator  for  Inquisitiveness  (a  personal 
enabling  characteristic). 
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•  Communication  Skills.  In  particular,  the  ability  to  "translate"  between  different 
stakeholders  such  as  engineers  from  different  disciplines  or  engineers  and  management 
team  members. 

•  Self-aware  individuals  who  are  self-starters.  These  are  personal  enabling  characteristics 
identified  in  Atlas  as  better  enabling  systems  engineers  to  grow.  Individuals  who  are 
capable  of  taking  initiative  and  working  independently  are  particularly  important  as 
systems  engineers  are  often  in  leadership  positions.  Self-awareness  is  critical, 
particularly  in  terms  of  enabling  systems  engineers  to  identify  when  they  need  to 
consult  SMEs. 

There  were  no  "hard  and  fast"  rules  for  identifying  systems  engineers,  but  the  above  reflect 
common  patterns  from  a  number  of  individuals  in  the  Helix  sample. 


6.6.  SE  Leaders:  How  Do  I  Use  This  Data  to  Build  My  Future  Systems  Engineering  Workforce? 

The  techniques  for  this  are  the  same  ones  as  identified  in  Question  6.4  above.  The  difference 
here  is  that  an  organization  needs  to  assess  not  for  current  skills  but  against  a  target  of  what  is 
needed  in  the  future.  When  the  Helix  team  asked  systems  engineering  leaders  what  the  future 
of  systems  engineering  would  hold,  there  often  was  hesitation.  Things  like  model-based 
systems  engineering  or  agile  systems  engineering  were  stated  -  but  many  organizations 
seemed  to  struggle  with  what  they  would  really  mean  in  their  context  and  how  they  would  be 
applied. 

The  Atlas  1.1  Implementation  Guide  provides  some  insights  on  how  to  plan  for  the  future  but 
does  not  help  an  organization  define  what  future  state  of  systems  engineering  it  desires. 
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7.  Conclusions 


Of  the  363  individuals  interviewed  for  Helix,  100%  agreed  that  experiences  were  the  most 
critical  Force  for  growing  systems  engineers.  Experiences,  combined  with  the  additional  Forces 
of  Mentoring  and  Education  &  Training,  make  up  the  career  paths  of  systems  engineers. 

This  Guidebook  provides  a  career  path  extraction  methodology  based  on  statistical  and  text 
mining  principles  to  be  used  by  systems  engineering  organizations,  systems  engineering 
leaders,  and  practitioners  to  identify  overarching  career  patterns  in  the  field  of  systems 
engineering.  Specific  career  patterns  aim  at  facilitating  systems  engineering  leaders  with 
confidence  when  identifying  new  or  potential  systems  engineers  for  projects. 

In  particular,  this  Guidebook  provides  information  on  patterns  in  career  paths,  including 
findings  in  terms  of  education,  experiences,  and  organizations;  frequently  asked  questions 
about  career  paths,  which  synthetizes  statistical  findings  reported  elsewhere  in  this  report;  and 
insights  on  relating  career  paths  to  proficiency  and  project  performance.  It  also  describes  the 
relationship  between  proficiency  and  project  performance. 

There  are  more  findings  throughout  the  Guidebook  than  can  be  singularly  summarized  here. 
However,  with  respect  to  the  patterns  in  the  careers  of  Chief  Systems  Engineers  (CSEs): 

•  Each  CSE  in  the  sample  had  a  bachelor's  degree;  for  18%,  this  was  the  highest  degree 
attained,  which  is  about  half  the  rate  in  the  larger  Helix  sample.  Over  8%  of  CSEs  held  at 
least  one  master's  degree,  which  is  20%  higher  than  in  the  overall  sample,  and  15%  held 
a  PhD,  which  is  nearly  double  the  overall  sample. 

•  The  most  common  bachelor's  degrees  majors  among  CSEs  include  electrical  engineering 
and  mechanical  engineering,  covering  more  than  two-thirds  of  the  CSE  dataset.  This  is  a 
higher  rate  than  seen  in  the  general  US  population  at  the  time;  however,  EE  and  ME 
were  the  two  most  common  engineering  majors  when  most  of  the  CSEs  were  going 
through  undergraduate  education.  It  is  also  in  line  with  the  distribution  of 
undergraduate  majors  across  the  Helix  dataset. 

•  In  contrast,  at  the  master's  level.  Masters  of  Business  Administration  (MBA)  is  the  most 
popular  major,  with  almost  50%  of  CSEs  holding  an  MBA.  This  is  nearly  double  the  rate 
of  MBA  attainment  in  the  overall  sample.  Systems  engineering  is  the  second  most- 
common  master's  degree  field  among  CSEs,  whereas  this  is  the  most  common  master's 
degree  field  in  the  overall  Helix  dataset. 

•  All  of  the  CSEs  in  the  sample  have  experiences  across  at  least  four  of  the  lifecycle 
phases.  Almost  all  CSEs  have  experienced  System  Definition,  System  Realization,  and 
Systems  Engineering  Management.  The  most  common  point  of  entry  for  CSEs  was 
System  Definition. 
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In  process 

A  paper  on  systems  engineering  career  paths,  "Discovering  Career  Patterns  in  Systems 

Engineering"  has  been  submitted  for  the  2018  INCOSE  International  Symposium.  The  authors 

are  Nicole  Hutchison,  Sergio  Luna,  and  Matthew  Partacz. 

Other 

ABET  Symposium  2016,  Fort  Lauderdale,  FL- ABET  panel  on  systems  engineering  education  and 
research  for  the  2016  ABET  conference.  Nicole  Hutchison  presented  on  Helix. 

INCOSE  Healthcare  Systems  Engineering  Working  Group  Webinar  -  November  29,  2016.  Nicole 
Hutchison  delivered  a  webinar,  a  60-minute  overview  of  Atlas  with  specific  implications 
related  to  healthcare  systems  engineers. 

10.  Appendix  C:  Paper-Based  Self-Assessment  Tools  for  Career  Path 


An  individual's  career  path  is  the  precise  combination  of  experiences,  mentoring,  education, 
and  training  that  an  individual  goes,  particularly  their  characteristics,  timing,  and  order. 
In  order  to  complete  a  career  assessment,  an  individual  should  work  through  the  steps 
outlined  here  while  filling  out  the  career  path  template. 

Experiences 
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The  Helix  team  chose  to  use  a  position  as  the  unit  of  measure  for  experiences;  a  position  is 
established  by  the  organization  and  defines  the  roles  and  responsibilities  to  be 
performed. 

Based  on  both  the  literature  and  the  Helix  data  itself,  each  position  has  several  characteristics: 

•  Relevance:  A  'relevant'  position  is  one  that  enables  a  systems  engineer  to  develop  the 
proficiencies  critical  to  systems  engineering.  Determine  a  starting  point  for  relevant 
experiences;  this  will  become  the  first  position  (PI)  of  the  career  path.  Fill  in  the  title 
and  the  year(s)  for  the  position(s). 

•  Organizations:  Fill  out  the  name  of  the  organization  for  each  position.  This  will  help  to 
show  any  transition  or  variation  between  organizations. 

•  Roles:  A  role  is  a  collection  of  related  systems  engineering  activities.  Roles  were 
identified  based  on  the  activities  consistently  performed  by  systems  engineers.  There 
are  16  roles  identified  in  Atlas,  as  described  in  Table  1,  below.  For  each  position,  review 
your  activities  and  responsibilities  and  write  down  all  roles  played  during  that  position. 

•  Lifecycle  Phases:  Generic  systems  engineering  lifecycle  phases  considered  in  Atlas  are 
based  on  the  lifecycle  phases  in  the  Guide  to  the  Systems  Engineering  Body  of 
Knowledge  (SEBoK),  as  explained  on  page  5.  (BKCASE  Authors  2016)  For  each  position, 
fill  in  the  area(s)  of  the  lifecycle  you  worked  on. 

•  Key  Milestones.  Note  any  key  changes  in  types  of  positions  under  key  milestones.  For 
example,  first  systems  engineering  role,  first  chief  systems  engineer  role,  first 
supervisory  position,  etc.  would  all  be  indicators  of  change  or  growth  over  career. 

Education  and  Training 

Note  any  educational  milestones  or  key  training  milestones  with  the  position/timeline  in  which 
they  occurred.  Education  milestones  may  include  the  completion  of  a  degree  or 
participation  in  a  course  that  was  particularly  relevant  or  impactful  for  your  career.  Key 
training  is  training  that  was  particularly  impactful  or  useful  for  your  career.  You  do  not 
need  to  include  training  that  did  not  have  an  impact. 


Other 


Your  organization  may  ask  you  to  add  other  information,  such  as  participation  in  professional 
societies,  publications,  etc.  to  your  career  path. 


Role  Name 

Role  Description 

Roles  Focused  on  the  Systems  Being  Devleoped 
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Role  Name 


Role  Description 


Concept  Creator 

Individual  who  holistically  explores  the  problem  or  opportunity  space  and 
develops  the  overarching  vision  for  a  system(s)  that  can  address  this 
space.  A  major  gap  pointed  out  to  the  Helix  team  -  particularly  when 
working  to  implement  the  findings  of  Helix  -  has  been  that  of  the 
development  of  an  overarching  system  vision.  This  is  a  critical  first  step 
in  the  systems  lifecycle,  and  several  organizations  stated  that  they 
believed  it  needed  to  be  separately  called  out.  In  addition,  when  looking 
to  the  future  of  what  systems  engineers  need  to  do  (e.g.,  INCOSE  Vision 
2025  (2015)),  the  focus  on  early  engagement  and  setting  the  vision  was 
deemed  critical. 

Requirements  Owner 

Individual  who  is  responsible  for  translating  customer  requirements  to  system  or 
sub-system  requirements.  This  is  updated  from  Atlas  1.0.  Sheard  (1996) 
also  included  the  activities  around  functional  architecture  in  this  role. 
However,  in  working  with  the  community,  this  has  caused  some 
confusion  as  to  the  differences  between  this  role  and  that  of  "System 
Architect".  The  Helix  team  believes  that  grouping  all  architecture 
activities  together  will  improve  clarity  on  the  roles. 

System  Architect 

Individual  who  owns  or  is  responsible  for  the  architectures  of  the  system;  this 
including  functional  and  physical  architectures.  This  is  updated  from 
Atlas  1.0.  This  is  an  update  of  Sheard's  "System  Designer"  role  (1996). 
There  was  concern  both  at  community  events  and  during  later 
interviews  that  nowhere  in  the  presented  framework  did  the  critical  role 
of  systems  engineers  in  architecture  come  out  clearly.  Some  also  argued 
that  "Design"  gave  the  impression  that  this  role  focuses  specifically  on 
the  details  of  systems  design  over  architecture. 

System  Integrator 

Individual  who  provides  a  holistic  perspective  of  the  system;  this  may  be  the 
'technical  conscience'  or  'seeker  of  issues  that  fall  in  the  cracks'  - 
particularly,  someone  who  is  concerned  with  interfaces.  Likewise,  there 
was  concern  over  the  word  "Glue",  which  many  expressed  was  not 
clearly  descriptive  enough. 

System  Analyst 

Individual  who  provides  modeling  or  analysis  support  to  system  development 
activities,  and  helps  to  ensure  that  the  system  as  designed  meets  he 
specification.  This  is  unchanged  from  Sheard's  roles  (1996). 

Detailed  Designer 

Individual  who  provides  technical  designs  that  match  the  system  architecture; 
an  individual  contributor  in  any  engineering  discipline  who  provides  part 
of  the  design  for  the  overall  system.  This  is  an  addition  based  on  the 
Helix  data.  While  systems  engineers  do  not  always  get  involved  with 
detailed  design,  in  smaller  organizations  or  on  smaller  projects  it  is  more 
common.  Likewise,  systems  engineers  who  had  played  this  role 
explained  that  it  was  critical  in  developing  their  own  technical  and 
domain  expertise  as  well  as  in  understanding  the  design  approaches  of 
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Role  Name 


Role  Description 


classic  engineers. 

V&V  Engineer 

Individual  who  plans,  conducts,  or  oversees  verification  and  validation  activities 
such  as  testing,  demonstration,  and  simulation.  This  is  unchanged  from 
Sheard's  roles  (1996). 

Support  Engineer 

Individual  who  performs  the  'back  end'  of  the  systems  lifecycle,  who  may 
operate  the  system,  provide  support  during  operation,  provide  guidance 
on  maintenance,  or  help  with  disposal.  This  was  previously  titled 
"Logistics  and  Operations  Engineer"  in  Sheard  (1996).  Flowever,  in 
interviews  and  at  community  events,  the  Helix  team  received  feedback 
that  using  this  title  gave  the  impression  that  this  role  was  limited  and 
did  not  encompass  the  full  spectrum  of  systems  engineers'  activities  at 
system  deployment  or  post-deployment.  Likewise,  in  several 
organizations,  "logistics"  and  "operations"  were  seen  as  separate 
disciplines  from  systems  engineering,  which  caused  some  contention  in 
discussions.  The  renaming  of  this  category  is  intended  to  address  these 
issues. 

Roles  Focused  on  Process  and  Organization 

Systems  Engineering 
Champion 

Individual  who  promotes  the  value  of  systems  engineering  to  individuals  outside 
of  the  SE  community  -  to  project  managers,  other  engineers,  or 
management.  This  may  happen  at  the  strategic  level  or  could  involve 
looking  for  areas  where  systems  activities  can  provide  a  direct  or 
immediate  benefit  on  existing  projects.  Sheard  recommended  that  a 
role  such  as  this,  labeled  in  her  work  as  "Systems  Engineering 
Evangelist",  be  added  in  (2000). 

Process  Engineer 

Individual  who  defines  and  maintains  the  systems  engineering  processes  as  a 
whole  and  who  also  likely  has  direct  ties  into  the  business.  This 
individual  provides  critical  guidance  on  how  systems  engineering  should 
be  conducted  within  an  organization  context.  This  is  unchanged  from 
Sheard's  roles  (1996). 

Roles  Focused  on  the  Teams  That  Build  Systems 

Customer  Interface 

Individual  who  coordinates  with  the  customer,  particularly  for  ensuring  that  the 
customer  understands  critical  technical  detail  and  that  a  customer's 
desires  are,  in  turn,  communicated  to  the  technical  team.  This  is 
unchanged  from  Sheard's  roles  (1996). 

Technical  Manager 

Individual  who  controls  cost,  schedule,  and  resources  for  the  technical  aspects 
of  a  system;  often  someone  who  works  in  coordination  with  an  overall 
project  or  program  manager.  This  is  unchanged  from  Sheard's  roles 

Report  No.  SERC-2018-TR-101-C 


109 


January  16,  2018 


Role  Name 


Role  Description 


(1996). 

Information  Manager 

Individual  who  is  responsible  for  the  flow  of  information  during  system 
development  activities.  This  includes  the  systems  management  activities 
of  configuration  management,  data  management,  or  metrics.  This  is 
unchanged  from  Sheard's  roles  (1996). 

Coordinator 

Individual  who  brings  together  and  brings  to  agreement  a  broad  set  of 
individuals  or  groups  who  help  to  resolve  systems  related  issues.  This  is 
a  critical  aspect  of  the  management  of  teams.  This  is  unchanged  from 
Sheard's  roles  (1996). 

Instructor/Teacher 

Individual  who  provides  or  oversees  critical  instruction  on  the  systems 
engineering  discipline,  practices,  processes,  etc.  This  can  include  the 
development  or  delivery  of  training  curriculum  as  well  as  academic 
instruction  of  formal  university  courses  related  to  systems  engineering. 
While  any  discipline  could  conceivably  have  an  instructor  role,  this 
denotes  a  focus  on  systems  and  is  a  critical  component  in  the 
development  of  an  effective  systems  engineering  workforce.  This  is  an 
addition  to  the  Sheard  roles  (1996  and  2000). 

Systems  Engineering  Lifecycle 

•  Concept  Definition  -  A  set  of  core  technical  activities  of  SE  in  which  the  problem  space 
and  the  needs  of  the  stakeholders  are  closely  examined.  This  consists  of  analysis  of  the 
problem  space,  business  or  mission  analysis,  and  the  definition  of  stakeholder  needs  for 
required  services  within  it. 

•  System  Definition  -  A  set  of  core  technical  activities  of  SE,  including  the  activities  that 
are  completed  primarily  in  the  front-end  portion  of  the  system  design.  This  consists  of 
the  definition  of  system  requirements,  the  design  of  one  or  more  logical  and  physical 
architectures,  and  analysis  and  selection  between  possible  solution  options. 

•  System  Realization  -  The  activities  required  to  build  a  system,  integrate  disparate 
system  elements,  and  ensure  that  a  system  both  meets  the  needs  of  stakeholders  and 
aligns  with  the  requirements  identified  in  the  system  definition  stage.  This  includes 
integration,  verification,  and  validation  (IV&V). 

•  System  Deployment  and  Use  -  A  set  of  core  technical  activities  of  SE  to  ensure  that  the 
developed  system  is  operationally  acceptable  and  that  the  responsibility  for  the 
effective,  efficient,  and  safe  operations  of  the  system  is  transferred  to  the  owner. 
Considerations  for  deployment  and  use  must  be  included  throughout  the  system  life 
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cycle.  Activities  within  this  stage  include  deployment,  operation,  maintenance,  and 
logistics. 

•  Product  and  Service  Life  Management  -  Deals  with  the  overall  life  cycle  planning  and 
support  of  a  system.  The  life  of  a  product  or  service  spans  a  considerably  longer  period 
of  time  than  the  time  required  to  design  and  develop  the  system.  This  stage  includes 
service  life  extension,  updates,  upgrades,  and  modernization,  and  disposal  and 
retirement.  The  organizations  in  the  current  sample  are  primarily  concentrated  on  new 
development,  so  this  is  a  very  under-represented  aspect  of  the  life  cycle. 

•  In  addition  to  these  life  cycle  phases,  the  SEBoK  includes  orthogonal  activities  of  systems 
engineers.  Systems  Engineering  Management,  defined  as  managing  the  resources  and 
assets  allocated  to  perform  SE  activities.  Activities  include  planning,  assessment  and 
control,  risk  management,  measurement,  decision  management,  configuration 
management,  information  management,  and  quality  management.  These  activities  can 
occur  at  any  point  in  the  systems  engineering  lifecycle. 
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Concept  Definition 
System  Definition 
System  Realization 
System  Deployment  and  Use 
Product  and  Service  Life  Management 
Systems  Engineering  Management 


Role(s) 

Performed 


Domain(s) 

System 

Characteristics 

Position 

Organization(s) 

Dates 


-c 

-c 


Milestones 
(Key  positions, 
education,  or 
training) 
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